Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Score лучший предсказатель, потому что в канале люди ведь не занимаются оценкой постов, они просто репостят то, что им в конкретный момент времени зашло.
Я правильно понимаю, речь идет об использовании одной модели (общей) в которую буквально текстом задают вопрос о сравнении? Но модели с этим изначально отвратительно справляются... даже если так делать, нужно так формулировать промпт, что бы модели нужно было для ответа дать один токен (да/нет) и вероятность этого токена (logits/logprobs, не каждый api дает к ним доступ) будет целевой неуверенностью модели в этом ответе, это уже число, с которым можно работать (прогнать такой промпт по старой базе постов и сравнить, вычислить закономерность, скорее всего там будет что то типа перекрывающегося множества часть тех постов для которых ответ да будет давать с хорошими шансами ответ нет но определенной вероятностью).
Но ведь для этого лучше дообучить свою модель, условно у нас есть база старых постов с оценками, тюним модель на следующий промпт ПостA -> оценка (только не численная а один токен, типа оценка от 0 до 9 да еще и зафиксировать жестко доступные токены с помощью structured output/gramma, для llm-ок это удобнее и дает лучше результат, а несколько разрядов в числах ее путают) и теперь сможем делать предсказание на базе своей модели, имея на руках оценку ее правдоподобности.
Точно так же можно тюнить и сравнение двух постов, даем два поста через разделитель и просим сказать 1 или 2 (например промпт - какая статья интереснее), что бы ответ был один токен, вероятность перед этими токенами даст нам численную информацию, с которой можно работать, типа или score = logit('ответ 1') - logit('ответ 2')
В эксперименте structured output, не один токен.
Идея с logprobs интересная — это даст confidence «бесплатно».
Но:
1. Файнтюн привязан к критерию. Начну писать про кулинарию вместо AI — модель переобучать. Поменяю ЦА с разработчиков на домохозяек — снова переобучать. TrueSkill работает на любом критерии, просто меняешь промпт.
2. Для 164 постов файнтюн — из пушки по воробьям
3. Logprobs в OpenAI API есть, но не на structured output
4. Главная проблема не в confidence отдельного сравнения, а в positional bias у Bulk
TrueSkill даёт confidence «из коробки»: σ (sigma) = неопределённость. Много матчей → низкий σ → высокий confidence. И работает на любых критериях без дообучения.
Файнтюн + logits точнее для стабильной задачи в продакшене с миллионами и миллиардами образцов. TrueSkill — для исследований и меняющихся критериев.
У себя я использую файнтюн только на задаче управления поисковыми фразами в агентстве - их там реально миллионы.
Я бы не просто 'новая тема - переобучать', а делал бы переобучение с появлением каждого нового поста (как он вылежится нужный период времени, например мы собираем лайки за первые сутки, первую неделю, первый месяц...).
Никто не требует обучать большую модель... можно собирать из постов embendings, добавлять к ним какие то свои цифровые параметры (размер статьи, количество подписчиков у автора, количество постов у автора и т.п. вплоть до времени дня или день недели публикации, расстояние до ближайшей популярной публикации в ближайшие сутки и т.п. много чего можно придумать) и имея на руках эту базу, обучить маленькую нейронку предсказывать целевое число на ней.
2. Для 164 постов файнтюн — из пушки по воробьям
в смысле 164... вам нужно выгрузить другие телеграм каналы (желательно вашей тематики) нужны тысячи, желательно десяток тысяч постов, потому что прогнозировать только по своей маленькой выборке действительно глупо.
upd. когда речь о маленьком количестве, кажется методы в статье имеют больший смысл, заморачиваться по крупному наверное неоправданно сложно
Тут вопрос один: не является ли это оверкиллом и не плодит ли новые точки недетерминированности/отказа.
у меня в канале есть пост про поиск для сайта на векторах. Так вот он рассыпался на запросе <дымо ход>. Да да, тот самый, который решается легким костылем к эластику разбивается в мире векторных эмбеддингов.
я прихожу к выводу, что надо тренировать эмбеддинги, но если мы тренируем его, то меняется все пространство векторных представлений, значит мы его переобраьатыыаем каждый раз после тренировки.
то есть в вашем примере мы получаем двойной файнтюн. И это лишь одно из возможных неудобств
не понимаю, зачем нужно тренировать эмбендинги
у вас опечатка/ошибка, которую используемая модель для извлечения эмбендингов не поняла... так используйте изначально другую.
какую бы модель использовали вы, чтобы решить эту задачу?
у меня плохо с практикой, я просто беру то что советуют
везде и все сразу говорят про intfloat/multilingual-e5 small/base/large (до 0.6b), если маленькие модели то для ку сегмента лучше наверное sber
ну там всякие sbert или rubert-tiny2
но главное другое, текст нужно перед подачей в модель вычищать, от ссылок например, и соответственно тут же можно и проверку правописания провести (правда я бы предварительно еще по параграфам прошел бы, классифицируя как тот же код или как текст, что бы не вылечить лишнего).
Ну вот на практике иногда трен эмбеддингов не такая плохая вещь. Тут же важно, чтобы задача решалась. Косяк из примера был на руберте. Но на данных из 1с вести себя криво начинает приблизительно всё.
Вот вы и сами говорите, что: предобработка, тесты моделей, замена моделей если начинается неадекват. То есть банальная задача рейтинга становится супер инженерной (дорогой).
Я в метариале описал методы, которые в основе своей примитивны. Не требуется предобработка. Точек отказа почти нет. Результаты адекватные.
да я собственно так и подумал, вариант в статье по простому заметно дешевле чем заниматься более сложной разработкой.. с другой стороны большую часть этого сможет сделать ИИ как кодер и девопс почти сам (просто непривычно и страшно давать ему полные права без контроля)
мне тоже это не нравится и полные yolo права я даю ему только на виртуалках.
у меня на днях появилась гипотеза ограничить все опасные действия хуками, если у меня получится направлять в ответ на сомнительные действия hook с exit code 2 и печатать причину в stdout/stderr — то вероятно я смогу перестать бояться, что мои пароли уплывут какому-то хакеру.
Как будто репостам не хватает нормировки по просмотрам, это важно
Заземление в реальную статистику репостов - отлично, но всё равно не хватает эксперимента по устойчивости предсказанного рейтинга между разными запусками модели (с разным рандомным сидом, или там стояла нулевая температура?) Если сид не влияет, то всё равно будет зависимость от порядка постов, если их перемешать.
Для TrueScore Batch это вдвойне интересно, потому что добавляется ещё фактор разбиения постов на батчи. Аргумент, что TrueScore можно считать инкрементально, не пересчитывая все сравнения при добавлении новых объектов, работает только при условии того, что полученные в итоге оценки более-менее воспроизводимы и устойчивы.
Интересная мысль. Попробую посчитать на днях.
Нас как бы интересует, насколько сильно мутирует топ N между независимыми запусками каждого из вариантов (есть подозрение, что bulk тут окажется на высоте из за позиционного предпочтения)
Я сделаю прогон на на выходных. Интересно посчитать. Если есть идеи по метрикам — накидывайте
прогнал по топ-20 посты для разработчиков. Коэф Жаккара 0,78 для TrueSkill, а Bulk 0,51.
чутьё подвело. 0,78 — это что то около 18 постов из топа пересекаются. для bulk — 11 постов пересекаются.
Прогнал 10 запусков × 4 метода × 7 критериев. Гипотеза не подтвердилась — Bulk оказался наименее стабильным
Std ранга 17,8 у Bulk — пост может прыгать на ±18 позиций между запусками. На box plots видны выбросы до 60-140 позиций.
Единственное исключение — критерий «boring» (Bulk: жаккард 0,82). Видимо, оценка скучности достаточно простая, чтобы модель справлялась даже при positional bias.
TrueSkill выигрывает и по корреляции с реальными репостами, и по воспроизводимости — усреднение по матчам сглаживает случайный шум.
А почему предполагается линейная зависимость между интересом (или сюрпризом, как обратной величиной вероятности события) и количеством репостов? Для нелинейных зависимостей корреляция неинформативна, а линейная тут под вопросом, репост действие многофакторное.
Я использовал в расчетах корреляцию Спирмена, не Пирсона. Спирмен — ранговая корреляция, она не предполагает линейность, только монотонность: если модель считает пост лучше, он должен получать больше репостов. Форма зависимости (линейная, логарифмическая, степенная) не важна.
По поводу многофакторности — абсолютно согласен. Репост зависит от времени публикации, охвата в момент поста, темы, длины, наличия картинки и ещё десятка факторов. Модель видит только текст.
Поэтому корреляция ~0,50 — это не «модель идеально предсказывает виральность», а «модель выделяет что-то релевантное из текста, что коррелирует с репостами». Учитывая шум от внешних факторов, даже 0,5 — неплохой сигнал.
Если бы я хотел предсказывать репосты точнее, добавил бы фичи: день недели, время, длину, наличие ссылок, эмодзи и т.д. Но задача была другая — сравнить методы сортировки между собой на одинаковых данных.
Если честно, то мне больше нравится как разбились посты на группы по интересам, чем предсказательная сила репоста. TrueSkill реально показывает себя отличным способом делать произвольные рейтинги.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как заставить LLM сортировать данные: от наивного подхода до TrueSkill