Алгоритм рекомендаций после загрузки файла для Инфостарта

К черту подробности. Язык какой?

Для примера, вот кусок лога
6828996 17.09.2015 14:53:04 Закрытие ошибок партионного учета Анализ ошибок партионного учета или Закат солнца вручную Да Akvals
6828994 17.09.2015 14:51:56 ТТН Внешние печатные формы ТОРГ-12, Счет-Фактура, 1-Т и ТТН для УТ 11 Да tiger
6828993 17.09.2015 14:51:32 Архив с обработкой и xsd схеммой Redmine - библиотека для интеграции с 1с Да shtyk80
6828992 17.09.2015 14:51:26 1-Т Внешние печатные формы ТОРГ-12, Счет-Фактура, 1-Т и ТТН для УТ 11 Да tiger
6828991 17.09.2015 14:50:39 ОбработатьДанныеПервичныхДокументов.epf Заполнение регистра сведений "ДанныеПервичныхДокументов" Да Lizi603
6828990 17.09.2015 14:50:22 Внешний отчет Внешний отчет по наличию счетов-фактур выданных Да serg999
6828989 17.09.2015 14:49:55 ПочасовыеПродажиЧекККМ.erf Почасовой анализ продаж по чекам ККМ Да IBRAGIM551
6828988 17.09.2015 14:49:34 Выгрузка и загрузка данных XML с отбором Выгрузка и загрузка данных XML 8.3 с отбором Да Neco
6828987 17.09.2015 14:48:52 Просмотреть подписки на события для объектов метаданных Подписки на события объектов Метаданных Да serg999
6828986 17.09.2015 14:48:44 ВыгрузкаЗагрузкаJSON_1.2.1.epf (8.3+) Универсальная выгрузка/загрузка данных для отличающихся конфигураций (JSON, Такси+ОФ) Да sarh
6828985 17.09.2015 14:48:41 УНФ_СФ_ВЫДАННАЯ_2012_1137_ Внешняя печатная форма Счет-фактура для УНФ 1.4 Да Eurosoft
6828984 17.09.2015 14:48:24 Акт выполненных работ (оказанных услуг) Акт выполненных работ (оказанных услуг) для Управления небольшой фирмой, ред. 1.4 Да Eurosoft
6828983 17.09.2015 14:46:06 Сравнение остатков регистров учета ТМЦ Сравнение остатков регистров учета ТМЦ Да Akvals
6828982 17.09.2015 14:43:01 Обработка расхождений по партиям(УУ) Корректировка партий по управленческому учету в соответствии с остатками товаров на складах (УПП, возможно УТ) Да Akvals
6828981 17.09.2015 14:42:23 Различие партий и остатков по оптовым складам 1С8.1 УТ, УПП Различие партий товаров и остатков по складам Да Akvals
6828980 17.09.2015 14:42:02 Акт сверки взаиморасчетов по нескольким договорам.erf Акт сверки взаиморасчетов по нескольким договорам Да 18101986
6828979 17.09.2015 14:41:39 Загрузка товаров с Яндекс.Маркет Загрузка товаров с Яндекс.Маркет Да agro23
6828978 17.09.2015 14:41:33 ГрупповаяОбработкаЗаменаПоРеквизиту Групповая Обработка Справочников И Документов (v.3.4) - замена реквизита выражением, удаление объектов - новая версия Да Sadir
6828977 17.09.2015 14:41:22 Перенос данных из УТ 10.3 в УТ 11 Перенос данных из УТ 10.3 в УТ 11.1 Да selinserg

В таблице только ID записи, ID файла, ID юзера и Date в unix формате.

https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0­%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%84%D0%B8%D0%BB%D­1%8C%D1%82%D1%80%D0%B0%D1%86%D0%B8%D1%8F

Наверно файлы грузят поьзователи-программисты и бухгалтера по их текщей потребности. Точнее потребности предприятий в текщий момент. Там сотни предпочтений выраженных через одни руки которые ищут. Наверно история их загрузок не важна в динамике развития. Только текущие потребности. Могу ошибаться. Но может хватит анализа частоты ключевых слов в названии файла или в его описании.

Индексируй постоянно свою таблицу по Пользователь + Ключевые слова (фразы),
Создай еще одну таблицу по частоте использования Фраза + Пользователь,
Выбирай По Второй таблице,

Удачи.

SEL ECT * FR OM table ORDER BY RAND() WHERE user_uid = 5 LIMIT 10;
Это если MySQL

По ID файла получаем ID публикации, получаем раздел (категорию) публикации и предлагаем пользователю ТОП-10 файлов из этой категории, которые он не скачивал. Предварительно надо только строить таблицу ID файла ID категории

Наверное, надо копать в сторону прикручивания словарной базы
http://www.solarix.ru/sql-dictionary-sdk.shtml

А я бы сделал так берем Файл который скачивает пользователь, потом ищем пользователей которые скачали этот-же файл, следующее смотрим какие файлы эти пользователи скачивали в течении +- 12 часов топ 10 этих файлов можно и предложить текущему пользователю.

Можно попробовать увязать историю пользователя с историей загрузки других пользователей. Выбрать наиболее похожую историю и отбирать 10 ссылок из тех что еще не попадали в историю загрузок нашего пользователя. Как функции сравнения можно использовать DIFFERENCE() и SOUNDEX() (возможно не дружат с кириллицей).

У нас немного похожая ситуация. У нас есть таблица или несколько таблиц с исходными данными. Для комфортного обращения и получения данных мы создали на самом сервере скл несколько "вьюх" таблиц скл. вьюхи формируются на лету по определенным отборам и результате мы обращаемся за нужными данными к определенной вьюхе. тест показал что обращение к вьюхе и получение из неё данных более быстрее чем обращаться за этими данными к исходной таблице.

Допустим создать вспомогательную таблицу. В ней 1000 наиболее часто встречающихся слов ВО ВСЕХ публикациях. Потом каждую публикацию оценить по этой 1000 слов. Т.е. частота этого слова в определенной публикации по отношению к частоте этого слова во всех публикациях. Слова фильтрануть глазами. Чтоб не было не относящихся к ИТ сфере.

Возможно не самый оптимальный запрос, но зато рабочий

Согласен. Однако если посчитать фактическую статистику то получится как бы сумма акцентов. Каждый когда пишет описание свой обработки чаще всего будет употреблять слова который важны были именно для него при создании обработки.

а почему рейтинги файлов не учитываются? и срок скачивания? вообще тут надо систему коэффициентов ввести.

срок публикации

Приветствую!
Знаете, где отлично решена подобная задача? В соц. сети ВК раздел - "Рекомендуемая музыка".
Там человеку действительно то, что ему нравится, рекомендуют. Если регулярно слушать музыку, то это очень заметно.

Там задача поиска рекомендаций решена, на мой взгляд, следующим образом. Смотрят, что слушают и добавляют люди, с которыми у тебя есть совпадения.

Таким образом можно попробовать в контексте текущей задачи как бы быть на шаг впереди пользователя. Берем последовательность из его трех последних загрузок. Ищем такую же последовательность у других пользователей. Если находим, то рекомендуем текущему пользователю то, что другие скачивали на следующем шаге. С большой вероятностью это окажется то, что и ему понадобится.

Вероятно, для инфостарта лучше последовательность длиной 1 смотреть. Но для 2-3-5 последних загрузок пользователя. То есть каждую рассматриваем индивидуально. И для каждой смотрим, что скачивали на следующем шаге те, кто скачивал то, что сейчас скачал пользователь.

Как думаете, так может сработать?

Где то читал что пытались на теплоходе построить систему анализа движения льдов на километр вперед. Чтобы предугадать и плыть заранее менее трудным путем. Слишком сложно и не предсказуемо. При чем иногда бывает что потребности пользователя и поисковый запрос не совпадают. Поэтому возможно подойдет рандомная выборка.

Интересная задача.
Тем, что, придумав алгоритм, можно будет оценивать успешность его рекомендаций.
Например, для пользователей с четными номерами применять алгоритм А, нечетными - Б.
У кого попаданий больше - тот и лучше.
И очень простая оценка: % попаданий (загрузки в любом будущем из 10-ки, не обязательно сразу).
Так можно построить адаптивные, самообучаемые алгоритмы.
И есть большой набор данных для проверки.
На половине выбрки - обучаем, на второй - проверяем.
Вообще - это классическая задача для БигДата.
Каждый пользователь взял набор товаров (файлов). Один - его только набирает.- Что еще ему можно положить?

Кая я понял, стоит задача сделать что-то попроще.
Но без дополнительных структур данных, кажется, не обойтись.
Пока не понял как можно эффективно задействовать время.

Варианта пока два:
1. "Частота пар". Заводим таблицу, куда складываем частоту пар: (Id1, id2, frequency). Когда очередной пользователь скачивает файл, генерируем пары из очередного файла и всех ранее скачанных и инкрементируем соответствующую частоту.
Чтобы таблица имела предел размера, можно строить простой Хэш(id1, id2) и считать частоту его значений.
Для нахождения Топ10 нужно для каждого файла найти сумму частот в паре со всеми отобранными пользователем и по максимуму этой суммы отобрать файлы.
2. Геометрическая близость.
Всем пользователям присваиваются координаты (две, три или больше - тут нужно подумать). При скачивании файла пользователь перемещается в геометрический центр всех ранее скачанных файлов, а файл - в геометрический центр всех скачавших его пользователей.
Рекомендуются ближайшие нескачанные файлы. Периодически потребуется разреживать это пространство путем масштабирования, а то оно будет сжиматься к центру.

Как-то так.
Но тут нужно пробовать на реальных данных.

Ну а одним запросом к исходной таблице вряд ли целесообразно, так как много вычислений будут повторяться от выбора к выбору.

(31. support) Предлагаю выдавать 2 варианта списка. 1 по понятиям банановой ловушки и 2й на основе вероятностного подхода

Вот самое простое что в голову пришло: (кстати фильтр по дате не указал намерено для краткости кода(без него никуда естественно) и прошу прощения за ошибки в синтаксисе: не было времени тестить)


Итак допустим tab-имя таблицы и idfile,id_user, datetime -поля , а file и user соответственно входящие данные
Вариант 1 по единственному файлу (что скачал пользователь )


по нескольким файлам что скачивал пользователь



З.Ы.
Если кроме анализируемого пользователя файл никто не скачивал то составляем топ по ключевым словам
Суть запроса такова: берем файлы что скачивал юзер втечение последних 30(напиример) дней затем вычисляем список пользователей которые тоже их скачивали, далее находим файлы скачаные втечениие последних 30 дней пользователями из найденого списка и строим рейтинг скачиваний. На этом все.

(0) задача классическая из CRM - формата "рекомендованный товар". Я сейчас в цейтноте, напишу чуть подробней завтра.

НО - я бы делал не на SQL. Для задачи мы в свое время использовали вот такой подход http://habrahabr.ru/company/yandex/blog/223121/ - то есть это что-то из разряда BI инструмента. А уже в SQL клали расчётные данные.

Может провести сначала опрос на сайте и выяснить с какой целью пользователи заходят на сайт, например я, скачиваю файлы для решения определённой задачи и мне больше бы подошли файлы, которые решают точно такую же задачу, или подобную.

Резюмирую: лучше расширить функционал тэгов.

Для начала хорошо бы провести классификацию пользователей. Разбить файлы на домены по виду (обработки, документы, статьи и т.д.), областям и т.д. Хорошо бы индекс построить по названиям и описаниям файлов. Подумать как это все на классы разбить. Если пользователь что-то читает/качает/загружает - относить в определенные группы по видам файлов/тематике. До запроса еще далеко, мне кажется )))
П.С. Хотя можно просто слова проанализировать и точно также присвоить каждому поле определенное какие слова чаще встречаются (в полнотекстовом виде, конечно) при загрузке/просмотре/лайках и так подбирать обработки.
П.С.П.С. А лучше просто общий тренд определить (т.е. что пользователи качают просто чаще, то и показывать)

Предлагаю внедрить выборку типа : "Выбравшие этот продукт также выбрали: .... "
Ничгео хитрого придумывать не надо. Потребитель вполне может ориентироваться на выбор таких же потербителей, которые искали то же что и он.

В реккомендуемые показывать результаты поиска, из которых пользователь открыл скачиваемую обработку.

То есть
1. Создаем таблицу пользователь, запрос, ид обработки из результатов запроса.
2. После запроса заносим туда информацию.
3. Если ИД скачанной обработки найдено в таблице запросов пользователя, тогда берем результаты запроса и уже по какому-то криетрию отбираем оттуда 10 обработок. (случайные, ТОП 10 или др.)

Конечно в этом случае приведенная статистика может не понадобиться, а может быть дополнительным критерием выбора.

"Проблему банана" можно было бы решить с помощью методики TF/IDF. Допустим, слово "Яндекс.Маркет", и "загрузка" встречается в конкретном описании 1 раз, а слово "в" - 3 раза. Присваиваем первым двум метрику TF=1, а третьему 1/3. Это поможет снизить ранг стоп-слов. Далее умножим метрики на IDF = log2(N/n), где N - размер выборки, а n - сколько раз встречается слово. Если имеем базу из 10000 файлов, "Яндекс.Маркет" встречается 10 раз, слово "загрузка" - 1000 раз, а "в" - 8000 раз, имеем соответствующие IDF, равные 9.9, 3.3 и 0.3. Перемножаем TF и IDF, получаем 9.9, 3.3 и 0.1.
Далее уже ищем файлы, которые имеют похожие сочетания слов с высоким рейтингом.

Я так понимаю, что задача без ключевых слов?
Тогда и думать нечего и нужно решать "в лоб".

Пользователь скачивает файл с кодом ХХХ. Первым подзапросом выбираем пользователей и время скачивания файла ХХХ. Вторым подзапросом получаем список всех файлов для фильтра из первого подзапроса в диапазоне +/- один час. Далее получаем ТОП самых частоскачиваемых и предлагаем пользователю. Готово!

На самом деле любую выборку из 10 ответов, т.к. условия задачи позволяют.

Всем привет! Я думаю, что на статистику опираться в любом случае нужно (т.е. накапливать различные частоты), т.к. вкусы и предпочтения людей не меняются быстро и имеют свойство отражать его потребности, склонности и даже характер. Кроме того, помимо поисковых запросов стоит учитывать деятельность пользователя на форумах и в комментариях к статьям(хотя это вроде одно и то же).
Кстати, ключевые слова вроде есть в статьях. Явные предпочтения пользователь показывает тыкая в звёздочку или скачивая файлики. Хм, может имеет смысл сделать взаимодействие с пользователями (хотя бы на первое время или тем, кто захочет, или за стартмани) - чтобы оценивать удачность рекомендаций или типа того (что-то вроде обучения нейросети).
С наскока задачу подобного класса вряд ли решить. Обязательно нужно почитать на эту тему прежде чем реализовывать. Мне кажется, что вам имеет смысл попробовать узнать, как подобные механизмы устроены в соцсетях, в гугле и т.п.

Исходная таблица:
ID (файл) UserID(пользователь) Date(дата)

п.1. Из исходной таблицы, получаем список ID, где UserID = ТекущийПользователь.
п.2. Из исходной таблицы, получаем список UserID, где ID входит в п.1
п.3. Из исходной таблицы получаем таблицу (первые 10) ID, КоличествоРазличных(UserID) сортированную по КоличествоРазличных(UserID)

Непонятна задача.

Надо пользователю выдать рекомендации на базе этой таблицы после того, как он скачал очередной файл.
Необходимо получить 10 id рекомендованных файлов.

10 id - это 10 рекомендованных файлов?
Какие критерии рекомендации? Надо сначала придумать критерии, по которым будем рекомендовать. Вообще это напоминает задачу для нейронной сети, но честно говоря входных данных маловато для каких-либо рекомендаций. Если только анализировать текст описания по id файла.

Аналогичные задачи решают специалисты Googl-a при выводе возможных поисковых строк человеку.
Где то читал о том, что чем больше информации накоплено по пользователю, тем лучше подбор вариантов поиска соответствует его предпочтениям.
При этом учитываются много видов данных:
Страна, регион, предпочтения, история поиска. и т.п.

Таким образом, чтобы максимально угодить человеку в предложениях имеет смысл учитывать:
1). Историю его скачиваний
2). Должность
3). Пол, возраст
4). Семейное положение
и другие параметры.

Что я имею ввиду? Строим большую таблицу статистик. Чем более обширная она будет, тем лучше будут варианты предложений пользователю.

Постепенно добавляем колонки в таблицу (см. предыдущее), добавляем статистику в разрезах этих данных.

Таким образом статистика скачиваний будет привязана к доп. разрезам.
При накоплении статистики можно добавлять в запрос доп. разрезы.

При первом старте запроса отбираем информацию по минимальному набору отборов, например, по последним 3 скачиваниям.

Если результатов запроса много - суживаем поиск, добавляем отбор по полу и возрасту.
Если вариантов все еще много, добавляем отбор по семейному положению.

Алгоритм можно продолжать до бесконечности.

Такой метод называется (может я и ошибаюсь) OLAP-кубом, а метод уточнения информации - анализ данных http://habrahabr.ru/company/airbnb/blog/237081/.

Есть даже целая профессия. Специалисты в этой професии очень ценны, с очень большой ЗП.
Такие специалисты особо ценятся в крупных компаниях, типа Google, Yandex и т.п.

Уважаемый автор темы! Поищите диссертации на тему - анализ данных.

Думаю, там вы найдете нужные вам алгоритмы. В Такой статье думаю нету смысла целую науку обсуждать!

На мой взгляд, одним списком не обделаться...
Думаю списка должно быть 2, а то и 3.
1. Список - ТОП 10 файлов, которые чаще всего скачивают со скачанным файлом (без учета тематики скачанного файла)
2. Список - ТОП 10 файлов, которые чаще всего скачивают со скачанным файлом (с учетом тематики скачанного файла)
3. Список - ТОП 10 файлов скачанных за последний период (день, неделю, месяц, год) типа как публикации на "БашОрге".

Если список сильно толстый, то можно ограничиться 5-ю файлами каждого раздела.
Что касается первых 2-х выборок, то эту задачу как уже выше писали, решают во многих областях, типа (С этим товаром чаще всего покупают..., С этой музыкой чаще всего слушают..., С этим видео чаще всего смотрят...) и готовых запросов и алгоритмов предостаточно.
Третий алгоритм решается еще проще, но он как раз будет держать в топе всегда одни и те же файлы. Для решения данной проблемы, в алгоритм можно задействовать рейтинг файлов, тогда действительно полезные файлы, которым "плюсуют" рейтинг будут подниматься в топ быстрее, но это же хорошо, пользователям того и нужно.
Ну про исключение из выборки ранее скачанных файлов думаю и так понятно.

если на 1С, то теги на файлы + http://v8.1c.ru/overview/PlAnaliz.htm (кластерный анализ или Поиск ассоциаций) или по тем же тегам строить метрику удалённости и опять же искать ближайшие

Работа оплачивается?

Исходя из того что в условии почти ничего не сказано ни про критерии ни про все остальное, напишем тупой вариант - "файлы которые качают те кто скачал этот файл в течении последнего месяца" на условном SQL
Предположим что у нас таблица FILES с полями, параметры запроса :USERID и :FILEID
TABLE FILES (FileID,UserId,Dte)
Тогда запрос будет выглядеть примерно так
SEL ECT FileId,COUNT(*)
FR OM FILES AS f1
WHERE Dte>=now()-30*24*60*60 AND f1.UserId IN // Скачанное за последний месяц и пользователь...
( SELECT UserId FR OM FILES AS f3 WHERE f3.FileId=:FILEID AND f3.UserId<>:USERID //... в скачавших этот файл за последний месяц, кроме нас
AND Dte>=now()-30*24*60*60 ) //ограничиваем историю последним месяцем
AND FileId NOT IN (SELECT DISTINCT FileId FR OM FILES WH ERE UserId=:USERID) // Исключим файлы, которые уже скачал данный юзер
GROUP BY 1 ORDER BY 2

На выходе список FileID, с указанием сколько раз скачивался, отсортирован по количеству.
В "банановой ловушке" как таковой я ничего плохого не вижу - если все качают а мы еще нет - почему бы не посоветовать. Но выход (я сознательно не вносил в запрос LIMIT 10) можно просеять рандомом и перемешать, тогда и ловушка не будет влиять. Проще это сделать уже кодом, получившим выборку, или заменить первую строку на
SELECT DISTINCT FileId
а последнюю на
GROUP BY 1 ORDER BY Random() LIM IT 10
Говорить об оптимальности запроса можно будет только после уточнения СУБД и объемов данных.

Алгоритм примерно такой:
1. Выбрать последних 100 скачавших
2. Для каждого из них выбрать по 10 скачиваний до/после по дате (может быть 5 до, 5 после или 10 до и 10 после)
3. Из полученного списка отобрать 10 наиболее часто встречающихся.
В идеале бы ещё давать оценку по интервалу дат от скачивания данного файла и скачиваний тех, которые собираемся рекомендовать...

Таким образом, при скачивании файла - мы будем рекомендовать не 10 наиболее часто встречающихся вообще, а 10, которые были скачаны совместно примерно в одно и то-же время.

Так то сперва нужно определиться, что рекомендуем пользователю. Это могут быть и наиболее скачиваемые и, совместно скачиваемые и, наиболее скачиваемые только бухгалтерами, или вообще не скачиваемые, а просматриваемые. и т.д (т.е. у нас пока не определены критерии). Например, если у пользователя нет стармани и он никогда ничего не качал, а только статьи читал, то зачем ему показывать наиболее скачиваемые? Разумнее ему показывать статьи и т.п.
Кароче, прежде всего нужно определиться с видами классификации пользователей и контента (определиться с механизмами для этого), а уже потом думать о критериях для рекомендации того, что этим пользователям стоит показывать.

Меня как пользователя скачивающего файлы для решения возникшей задачи, в первую очередь интересуют альтернативные решения имеющиеся на ИС. И только во вторую очередь файлы соответствующие моим обобщенным интересам...
Следовательно разумно предлагать компиляцию двух запросов (6 не скаченных альтернатив + 4 ходовых общих)...
1) Вероятно следуем всем файлам приписывать категорию (комбинация классификационных признаков) для быстрого отбора имеющихся файлов той же категории. Присваиваем им рейтинговый коэффициент по совпадению слов текущей статьи и имени файла. Отбрасываем уже скачанные пользователем. Для полученного фильтра считаем частоту скачки. Свежие закачки должны весить больше, чем годичной давности... Получаем Топ6 с учетом рейтингового коэффициента.
2) Топ4 закачек пользователей с моей классификационной категорией за последний месяц.

На основе одной таблицы - как не выёживайся особо не нарекомендуешь.. результаты будут получаться убогими, ИМХО.
Можно попробовать инструмен платформы "поиск ассоциативных правил".. В интернете есть публикации по предсказанию покупок на основании чека пользователя.. тут чеком будет последние скачанные файлы.

Но интереснее было бы давать более-менее индивидуально - по группам интересов. .

Для этого:

1) "Кластеризируем" пользователей по группам интересов на основе совпадения списка файлов, которые они закачивали.. возьмём, например, последние 10 файлов - это то, чем человек интересовался последнее время..
2.1) Для каждой группы составим частотный "словарь" ключевых слов в названиях публикации
2.2) Так же можно использовать группу и классификатор типа каждой публикации, откуда взят скачанный файл (авторы же указывают же - что это за публикация, что за платформа, конфигурация и т.п.) - и использовать эту инфу для кластеризации и предсказания..

4) На основе этих данных можно "предсказать", что за интересует этого пользователя - и выдать список рекомендуемых файлов, исключив те, что он уже скачал (с учётом версии)..

Технически - все можно сделать силами платформы 1С, если оттуда не убрали следующие вещи (делал что-то подобное на 8.1 платформе, анализировал простую статистику и кластеризировал данные пациентов по разным признакам для одной чужой научной работы - чисто "по приколу" - но не могу найти источник или статью, которая помогла мне ):

Для освоения всего этого есть отдельный курс у 1С - там много интересных инструментов встроенных в платформу 1С рассмотрено, подходящих для реализации разных подходов к этой задаче:
http://www.1c.ru/news/info.jsp?id=11609

Мне кажется вы все слишком усложняет.
Запоминаем:
СкаченныйID = файл, который скачал пользователь
ТекущийПользователь = сам пользователь, для кого ищем подборку топ 10.

Для получения предложений после скачивания можно воспользоваться "опытом других пользователей":

1. выбираем список других пользователей тоже скачавших этот файл
ВЫБРАТЬ РАЗЛИЧНЫЕ Пользователь
ГДЕ ID=СкаченныйID И Пользователь <>ТекущийПользователь

2. смотрим какие файлы скачали эти пользователи
ВЫБРАТЬ IDФайла, Дата-время
ГДЕ Пользователь В ТаблицеПользователей_Из_Пункта1

По идее Перед сворачиванием Таблицы по полю IDФайл нужно рассчитать "вес" файла от даты скачивания... чем свежее были скачивания тем выше вес и чем чаще файл скачивался, тем тоже выше вес... коэффициент для частоты скачиваний берется из расчета что важнее: свежие скачивания или частота?.
Заменяем верхний запрос на что то вроде:
ВЫБРАТЬ IDФайла, ВСЕГОДНЕЙСУЩЕСТВУЕТБАЗА - (ТЕКУЩАЯДАТА - Дата-время) КАК ВесПоДате, 1*коэффициент КАК ВесПоКоличеству, ВесПоДате+ВесПоКоличеству КАК ОБщийВес
ГДЕ Пользователь В ТаблицеПользователей_Из_Пункта1
ВЫГРУЗИТЬ
И
СВЕРНУТЬ ("IDФайла,"ОБщийВес ")

3. Далее сортируете и берете топ 10
Надеюсь понятно описал

запрос во втором пункте можно упростить
ВЫБРАТЬ IDФайла, СУММА(1*коэффициент - (ТЕКУЩАЯДАТА - Дата-время) ) ОБщийВес
ГДЕ Пользователь В ТаблицеПользователей_Из_Пункта1
ГРУППИРОВАТЬ ПО IDФайла
СОРТИРОВАТЬ ПО ОБщийВес
ВЫБРАТЬ ТОП 10

Умозаключение по поводу поиска аналогичных программ.

Поскольку в задачи стоит что топ список надо показать !ПОСЛЕ! того как человек загрузил себе файл, то понимая, что он уже произвел покупку, нес смысла ему предлагать аналогичный (по тексту, и по смыслу или скаченный в тоже время), так как он уже проделал отбор и выбор конечного результата... нужно предлагать в стиле "СОВЕСТНО С ЭТИМ ОБЫЧНО ПОКУПАЮТ ЕЩЕ И ЭТО"... "ИЛИ СОВЕРШЕННО ДРУГИЕ ПОПУЛЯРНЫЕ СКАЧИВАНИЯ" для того чтобы пробудить другую потребность, так как имеющаяся потребность уже реализована (закрыта).

Помойму самое верное это найти те файлы которые качали вместе с этим файлом, как было выше сказано зачастую люди качают файлы из-за того что они столкнулись с той или иной проблемой при работе в программе и начинают её решать и было бы не плохо показать что качали, пользователи возможно столкнувшиеся с аналогичной проблемой

А простите, в чем смысл делать анализ файла после закачки? Если перед закачкой дать какие-то рекомендации или на ссылки локальные уже скачанные, это понятно, а потом то смысл какой?

Это не четко поставленная задача. Что значит "выдать рекомендации на базе этой таблицы" ? Какая конечная цель у пользователя, который скачивает эти файлы ?
Можно выдать вот такую рекомендацию после очередного скачивания - "Выключи компьютер и иди обедай". Это самая лучшая рекомендация, потому что в задаче нет критерия чем она хуже или лучше любой другой.

Прошло три года, а воз и ныне там. До последнего времени работал «банановый алгоритм». Рекомендуем топ за последние полгода.
Может какие сервисы рекомендательных движков посоветуете?
Дополнительно к условию задачи есть теги, категории и другие классификаторы каждого файла, но субъективные. Автор или модератор могли ошибиться или не хватило классификатора.
Есть полнотекстовый поиск по публикациям.