В тему поста выше, подписываюсь под каждым словом

Полностью согласен. DSы часто абстрагируются от реальной бизнес-задачи и углубляются в рост исключительно ML-метрик

Но бывает и обратное: бизнес-менеджеры воспринимают DSов как инструмент для роста NDCG/Gini, а не как специалистов, способных формулировать бизнес-гипотезы и создавать новые пользовательские сценарии. ИМХО, в начале карьеры оказаться у такого менеджера может застопорить рост на долгие годы.

Главная проблема в том, что оптимизация метрик в рексисе часто сводится к улучшению алгоритмов в рамках текущей продуктовой модели и текущего датасета. Правильно выбранные метрики позволяют системно улучшать качество, и это действительно даёт дельту в существующих бизнес-метриках.
Но не менее важно DS специалисту помогать бизнесу в поиске и генерации новых сценариев, которые позволяют развивать бизнес не только в глубину(улучшение текущих метрик, на текущих датасетах) а так же и в ширину (добавление новых паттернов потребления itemов, новые пользовательские сценарии и тд), это все позволяет бизнесу иметь дополнительную устойчивость и гибкость.

Несколько примеров почему важен этот "широкий" вижн:

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

В поиске десятилетиями улучшали NDCG, @K метрики и тд, но теперь их значимость на бизнес снижается, потому что люди перешли на чтение ответов от LLM в самом начале выдачи, где уже собраны ответы на большую долю пользовательских сценариев

Spotify, когда внедрили свои discover weekly - они могли продолжать выбивать лучшие метрики на уже известных и больших точках рекомендаций, но придумали как рекомендации можно по другому упаковать и это дал сильный рост

Главная мысль в том, что DS это связующее звено между бизнесом и алгоритмами, и думать, и действовать он должен не только как kaggle-grandmaster (выбить максимум на заранее оговоренной метрике на текущем датасете), а сочетать в себе множество ролей, которые охватывают продукт целиком (Product, ML, DA, DE и тд) и думать DS должен не только о том, как добить заветные ndcg/auc и тд, а о том как в целом менять пользовательский опыт таким образом, чтобы это позволяло бизнесу расти

Чеклист здорового мл проекта

В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга, то вот моя выстраданная горьким опытом версия для МЛ:

1. Цель проекта ясна
Очевидно, но есть ньюансы: Вам могут говорить, что хотят денег заработать, а на деле пытаются обогнать внутренних конкурентов и занять поляну. Или же ожидают, что сделав Х - автоматически получат У. Настоящую цель вам могут не сказать, но ее можно выяснить вопросами типо «а вот представь мы запустили Х, и получим не У а Z, это будет считаться успехом?»

2. Все требования оцифрованы и измеримы
Не только ключевая цель проекта, но и разные неявные ожидания от системы (безопасность, косты инфры, дайверсити). По каждому из значений метрик можно однозначно сказать: система ок или не ок.

3. Продуктовый дискавери сделан
Проверочный вопрос: а давайте представим, что все сделали идеально, правда ли мы увидим ожидаемые эффекты? Иногда это сложно понять не эимплементировав систему, но boy oh boy, как часто это можно сделать малой кровью, понаблюдав за действиями пользователей системы. Особенно это больно в GenAI, где ускоряют кусочек бизнес процесса, а общего ускорения не происходит; протолкнули ботлнек дальше по пайплайну, и все.

4. Экспериментальный цикл - короткий
Т. е. качественные оффлайн прокси метрики. Офлайн метрики для принятия решений сходятся по вероятности к значениям целевых метрик (хотя бы из одного распределения). Доверительные интервалы метрик - оценены (и у разметочных метрик дисперсия не только от размера выборки зависит, а еще от качества работы разметчиков). В офлайн измерениях тоже есть серые тесты.

5. Все решения принимаются через эвалы
Нет «волшебных чисел» или «волевых архитектурных решений». Если в проекте спорят, что лучше работает - это красный флаг, надо проверять на цифрах.

6. Начали с бейзлайна
Вы не поверите, как часто бейзлайн обгоняет сложные решения. Просто потому что в бейзлайне сложнее накосячить.

7. R&D бэклог опирается на аналитику
В автоматизации ошибки системы на эвале распричинены до руткоза. В персонализации фичи опираются на поведенческие или количественные исследования (или хотя бы здравый смысл). Если весь бэклог - это список архитертур моделей, то это плохой беклог. В идеале дифф между целевым значением таргет метрики и текущем должен быть полностью обьяснен и атрибутирован конкретным причинам.

8. Большая часть усилий уходит на работу с данными
Команда не пытается подстроить систему под имеющиеся данные, а активно эти данные меняет (вычищают мусор, переписывают источники, анализируют фичи).

9. Система покрыта интеграционными тестами
Мало толку от идеальной модели, если ее скоры перетираются по дороге. Особенно больно с инференсом LLM, где обновление рантайма может изменить поведение модели.

10. Эксперименты логируюися и воспроизводимы
В ответ на «мы уже это пробовали» можно посмотреть, а что конкретно пробовали, и если нужно вернуться к идее, но в чуть другой постановке.

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

Ну и естественно, предполагается, что инженерная культура хорошая, млщики вычищают лики, не косячат в написании трейнлупа и т д. Этот чеклист не гарантирует успеха проекта, но если у вас проставлено меньше 9 галочек, то это плохой знак.

Мы тут с женой решили посмотреть какой-нибудь comforting фильм из нулевых, и остановились на комедии «Марли и я». Это кино про семью, которая завела собаку, и та сыграла важную роль в их жизни. Но я совершил стратегический проступок, предложив на двух третях фильма прерваться и пойти спать (а досмотреть на следующий день). В итоге первый день мы посмотрели легкую семейную комедию, а второй вечер смотрели драму про кризис среднего возраста и умирающую собаку.

Не повторяйте моих ошибок.

GenAI - это, конечно, инвестиционный пузырь, но именно поэтому заниматься его внедрением надо сейчас
И почему нарратив про продавцов лопат - это булшит

Мне видится, что за прошлый год бизнес среда окончательно поделилась на два лагеря. Технооптимисты, обещающие нам ИИ-сингулярность и автономных агентов десятки процентов роста GDP, и пессимисты, которые грустно смотрят на P/E техно-компаний из S&P, и недоумевают. Кто прав?

Мой тейк: правы и те, и те. GenAI на длинном горизонте действительно даст десятки процентов GDP, но инвестиции в флагманские инфраструктурные компании никогда не окупятся теми иксами, на которые нам намекает их капитализация. Потому что у этих китов парадоксально нет рычага на извлечение львиной доли маржи.

По порядку. Откуда десятки процентов GDP? Ну давайте взглянем на 3 основных источника ценности.

1. Профессия разработки изменилась, и новые продукты создаются быстрее. Особенно с выходом моделей конца 2025-го года. Писать код вручную выглядит как анахронизм. Причем в наибольшем выигрыше опытные инженеры, которые знают, чего они хотят от ллм (их эффективность выросла на 20% - на этой цифре сходятся большинство серьезных исследований). При этом автономные кодинг агенты, которые создают сложные системы без человека - это все еще лабораторные прототипы, но вот быстро пробежать первую милю до MVP они помогут уже сейчас. Соло девелоперы, запускающие полноценные бизнесы уже никого не удивляют.

2. Диджитал (и не только) профессии усилились в разы.
Копирайтинг, маркетинг, управление контентом, аналитика - атомарные кусочки этих конвейеров уже ускорились за счет ко-пилотов. Более 60% сотрудников S&P 500 регулярно используют эти инструменты в работе. Со временем случится и кумулятивный эффект. По оценкам антропика это все незаметно дает +2%% GDP (нифига себе). Нецифровые профессии - готовятся.

3. Энтерпрайз автоматизация идет, но тяжело
Оказывается, что сначала нужно пройти все стадии цифровой трансформации, покрытия глубокой аналитикой (в народе - бигдата), и только потом можно сверху строить ИИ. Но и там где это все сделано, запустить пилот очень просто, масштабироваться без заметных прокрасов метрик - сложнее, а вот сделать большой и стабильный аплифт - очень тяжело. Приходится менять сами бизнес процессы, а не только втыкать ИИ. Но реально: лидеры уже далеко зашли по этий дорожке, и сомнений в успехе нет.

И казалось бы, если ты OpenAI - бери и отжимай маржу через цену за токен. Но все не так просто:
- выжимать деньги из B2C клиентов сложно. Конкуренция острая, и опенсорс не спит. Потеряешь рынок.
- выжимать деньги из В2В - опасно. Им на своей стороне надо еще сделать огромную работу, чтоб это все полетело. Если задушишь их еще и ценой - плюнут и не будут ничего делать. Попробовать самому забраться повыше по цепочке добавочной ценности - нереально (пытаются конечно, через дженерик автономных агентов, но пока выходит плохо). Каждое внедрение уникально, сотни вертикалей. Просто талантов не хватит всех окучить, даже имея бесконечные деньги. Так что приходится партнерство строить, а не быковать.

И получилась интересная ситуация. Чуваки с деньгами понимают, что происходит что-то значимое, пытаются заработать на хайпе и несут деньги в OAI, nvidia, you name it. А они не умеют возвращать инвестиции. Они могут только лопаты раздавать, а существенная часть добавочной ценности на стороне реальных компаний, которые продукты людям строят (и будут делиться маржой со своими стейкхолдерами). Но вы за OAI и софтбанк с шейхами не переживайте - они на IPO бабушкам свои убытки продадут.

А вот если вы строите реальньные продукты, и улучшаете операции опираясь на GenAI, то мои поздравления. Чуваки у которых много денег и мало экспертизы проинвестировали вам офигенный рычаг. Аккуратно считаем PnL проектов, двигаемся осторожно, пилотами, и большая часть маржи осядет в вашей компании (ну и частично у вас 😉). Кайф же.

Пейпер нашей фундаментальной команды приняли на EACL’26 🎉

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

Не высовывайся

Вот вчера у меня до пол второго ночи четверо серьезных мужчин ходили по квартире, прикладывали ухо к полу, переодически замирая на месте шепотом восклицали «во, во, пошло» и переговаривались по рации с подвалом, где перекрывали по очереди все инженерные коммуникации. Кто меня хорошо знает, думаю, догадались, что речь идет про судебную экспертизу по моей годовой тяжбе с жилищником и МОЭКО из-за шума от коммуникаций. Экспертизу провели, и сразу так и сказали, что собран инженерный узел из говна и палок с нарушениями (это еще мягко сказано, моя жена, делавшая пусконаладку нескольких крупных предприятий выразилась покрепче). Короче, кажется дальше дело техники (тут огромное спасибо мега-крутому адвокату, заходите за рекомендацией), и дальше борьба уже с другим источником беспокойства вызванного рукожопостью.

Но когда мы с экспертами лазали по квартире, и те искренне разделяли мое негодование, я думал о другом. О том, как меня раз десять посылали подальше в УК, когда я пытался договориться по хорошему. Как убеждали, что никакой проблемы нет, а я один на весь дом такой. Никто же больше не жалуется (ну ладно, один жаловался, но перестал). Че высовываешься?

Зато поскандалить в чате дома о каких то мелочах все в очередь выстраиваются. Мне тут наверное еще повезло, в доме много неравнодушных людей, которые искренне пытаются отстоять общие интересы дома и вкладывают в это силы. Но большинство, конечно не высовывается. Да и я сам чаще всего. Всегда есть хорошая причина.

А иногда наверное надо, просто чтоб жизнь почувствовать. Чтоб с четырьмя серьезными мужчинами играть в час ночи у себя дома в «морская фигура на месте замри», глядя на показания шумометра. Когда еще такой шанс выпадет?

Чем заканчивается любой банковский брейншторм на любую тему

Платформенные продукты vs касдев

В какой-то момент карьеры мне подвернулась очень крутая возможность пойти строить AI SAAS в быстрорастущем стартапе. Классные фаундеры, понятный ров, растущая клиентская база, известный фонд прикрывает деньгами, международные продажи, короче мечта.

Год работы спустя мы с командой запускаем продукт, выходит статья про нас на техкранче, батлкарды написаны, короче готовы. Официальный запуск 22 февраля 2022, и уже через два дня планы наши начали довольно резко и необратимо меняться по понятным всем причинам. Потом мы заработали компании денег совсем другими вещами, и это уже совсем другая тема, но вот история моей AI платформы на этом по большому счету закончилась.

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

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

Было два ньюанса.

Этот идеальный конструктор был несовместим с тулчейном касдев команды. Тот был не МЛ-изированный и элегантный, но зато легко адаптировался под любые дикие хотелки клиентов. Разница была как между военной и гражданской техникой: где военная техника не отличается удобством и эргономикой, но зато максимально ремонтно пригодна и проста для модификаций. Вот я и строил айфон для людей, которым нужна была walkie-talkie рация.

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

Я этот урок выучил. Уже в Т, когда мы строили AutoML платформу мы действовали совсем по другому: мы начали с того, что долго делали касдев и шаг за шагом обобщали свой опыт инструментами. В итоге набор платформенных инструментов был прост в обслуживании и модификации, недорогим в разработке, и нам было не жалко его забросить, когда он себя исчерпал. А мы смогли из этой активности запустить целое направление контентного менеджмента для екома в Т-Банке и автоматизировать разметки на сотню с лишним миллионов в год.

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

Бойтесь своих желаний…

Деконструкция советских комедий

Я видимо старею, но на этих новогодних праздниках с небывалым удовольствием пересмотрел все главные советские комедии. И сейчас стал подмечать, что Новосельцев работает в опенспейсе, которому позавидует большинство современных офисных работников (работягам с водного привет!), модная квартира на мосфильмовской из «Москва слезам не верит» до сих пор вполне себе востребованная недвижка, а сами истории в корне своем почти не стареют.

И я вспомнил о совершенно фееричном выступлении Жоры Крыжовникова Андрея Першина на тиньковской продуктовой конфе «продукты 24» двухлетней давности, где тот разбирал режиссерские инструменты управления зрительским вниманием в советских комедиях. И это оказалось не менее интересно, чем эти самые комедии смотреть. Хочется думать, что именно это выступление сподвигло его запустить свой канал, где он развил эту тему в серию лекций по самым знаковым фильмам Данелия, Рязанова и Гайдая.

И я как наноинфлюенсер хочу отдать дань Андрею и порекомендовать его канал, чтоб его аудитория росла (хоть и на сотню человек, но зато каких!) а он и дальше радовал своими разборами. А если посмотрите другие видосы с канала «карты, деньги и продукт» по первой ссылке, то можете найти и мое там интервью

LLM-as-a-judge - индустриальный антипаттерн

Есть в AI индустрии две инженерные идеи, которые с распространением ллм-технологий на мой вкус стали антипаттернами. Это LLM-as-a-judge и векторный поиск. Их объединяет то, что они не требуют ментальной нагрузки при внедрении (easy), но при этом непрозрачно прячут под капотом огромную сложность (not simple). Про эмбеддинги поговорим потом, а вот с llm-as-a-judge давайте разбираться.

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

Но вот проблема: этот промпт надо написать. А для сложных сценариев надо еще и подложить в этот промпт какие то данные о внешнем состоянии системы в тесткейсе. Уже выглядит как задачка на context engineering. А как из всех возможных промптов выбрать тот, который реально работает? Видимо руками размечать. Кажется, что и ок, руками разметили один раз, а потом у нас автоматический оценщик. Ну так то тоже мимо: дрифт ответов системы (а это буквально задача R&D - сдрифтить ответы системы в сторону правильных), и все, по хорошему надо переразмечать качество джаджа.

Ну ладно, есть задачки где промпты-инструкции простые. Там то все хорошо? Ну вот нет: модели же еще и игнорируют эти инструкции. Опять же в разном проценте случаев на разных распределениях аутпутов системы. Один раз посчитать и забыть не получится.

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

Когда же llm-as-a-judge полезен?

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

2. Джадж - это часть композитного реворда для алаймента. Тут все ясно: даже неидеальный рекорд может накинуть метрик.

3. Джадж удешевляет человеческие разметки. Например схема с перекрытиями, где один из размерчиков - это ллм. А лучше ансамбль разных ллм.

4. Вы учитесь строить продукты. Тогда действительно пофиг на финальное качество, главное, чтоб сложилась культура работы с хоть какими то метриками.

В остальных случаях я убежден, что llm-as-a-judge - это бомба замедленного действия, которая дает ложное чувство контроля.

Некоторое время назад у меня была очень странная цепочка знакомств, встреч и разговоров, которые пошатнули стабильность внутреннего компаса ценностей. Когда ты думаешь «Блин, а может быть я просто слишком наивен? Может быть я одел белое пальто, и размышляю о высоком, а на деле надо грызьться за каждый клочёк места под солнцем. Может быть я не на тех людей смотрю, как на ролевые модели».

Вот этими мыслями я приболел. К счастью близкие люди были рядом и быстро смоделировали куда такая дорожка ведет, и почему ничего хорошего в этом нет. И окончательно вернула волю к жизни в этом мини-кризисе мне статья Сартра: «экзистенциализм - это гуманизм».

Если попробовать ужать ее досуха (что, конечно, преступление), то мысль там простая: человек - это проект, который сам себя строит. И в этом проекте важны и имеют ценность и вес только дела. Все попытки сконструировать другую ценность извне - иллюзорны и несостоятельны. А строя себя ты строишь человечество.

В этом контексте он привел классный пример: во времена оккупации Франции к нему пришел ученик и спросил, как правильно поступить: остаться с ослабевшей матерью и спасти ее от смерти в одиночестве или пойти в сопротивление и бороться с нацистами. Ни одна моральная система не могла помочь в этой конкретной ситуации. Сартр отказался ему что-то советовал, мотивируя тем, что «ты и есть твой выбор в этой ситуации» (если совсем упрощать). Более того парень решал не только за себя в тот момент, но и за все человечество (потому что в один в один такой же выбор во всех деталях больше ни один человек не попадет). А значит его выбор значит очень много.

Так что выбирая что-то противное вопреки себе - ты подрываешь свой собственный проект. Взамен можно получить много: наивным тоже быть не надо, но я думаю все, кто сталкивался с сверхуспешными людьми, понимают какую цену те платят за свой успех. Да и как правило они очень искренни в своём личном проекте и пирамиде ценностей, и не платят налог на то, что предают какие-то свои идеалы (хотя тут сложно в голову залезть, кто знает).

В итоге, остаться верным своим ценностям - я верю, что правильный выбор, даже если за это придется заплатить дорого.

А с векторным-то поиском что не так?

Обсудили, как llm-as-a-judge стал антипаттерном, который непрозрачно прячет под собой большую сложность, теперь давайте поговорим про векторный/семантический поиск.

Если смотреть на эту технику абстрактно - все с ней ок. Задача построения эмбедов снижением размеренности пространства с нами давно, олды из NLP вспомнят LDA/LSA, олды (и не очень) из рексиса матричную факторизацию. Первый ренессанс в широких инженерных массах у векторного поиска случился в середине десятых, когда все распробовали word2vec. Это действительно был очень свежий и классный кусок теха: unsupervised метод, дешевый в обучении (а чаще сразу предобученный) и инференсе, который укладывает семантически близкие слова близко друг к другу в пространстве эмбедов. Обещал с ноги закрыть проблему синонимов-парафразов, морфологии (в фасттексте), а с небольшими допилками еще и мультиязычности. Именно тогда если помните был первый бум чатботов, алексы и т д. Как раз потому что это была простая в реализации и доступная не-млщику технология семантичнского поиска.

Потом правда наступило похмелье: оказалось, что на многих задачах этот метод не обгонял bm25. Непонятно как дружить со структурированными текстами. Он либо работает как надо сразу из коробки, либо получить желаемые свойства очень сложно (единственная нормальная ручка - строить модель поверх). Он не решает вопрос замешивания не-текстовых фичей. Короче в серьезных продуктах все остались на классическом retrieve-rerank, где векторный поиск генерит кандидатов и используется фичей в ранжирование. Ну или стали инициализировать ими сетки для трейна на задачу.

Проходит чуть меньше 10 лет и про векторный поиск опять начинают говорить «все и их мамы». В этот раз в контексте RAG систем и context engineering’a LLM. С тех пор эмбеддинги у нас научились строить поверх предложений, а не слов. Считаются они трансформером, в не лежат в словаре. Но суть та же: unsupervised метод как-то сближает в среднем похожие по смыслу предложения и расталкивает разные.

А болячки все те же. Но в этот раз на них посмотрели не млщики, а армия креативных SWE и сбросив с парахода современности задачу IR начала сначала:
- 50 оттенков чанкинга
- а давайте к чанкам метаданные приписывать еще текстом
- агент, который через MCP сам себе собирает нужный контекст
- надо агенту дать почитать заголовки документов и тулу которой он может достать контент того, что он считает нужным
- mcp уже пробовали?
- диприсеч!
- перепишем все базы знаний, чтоб агент в них разобрался
- и конечно же каждый из методов оборачиваем в фреймворк, который несовместим с 15 уже имеющимися

Ну и это ожидаемо: даже очень классные SWE как правило не привиты дата-дривен культурой и базовой насмотренностью в области IR в той же степени, что и MLE (хотя справедливости ради и многие MLE тоже). Из-за этого в руках оказывается любимый молоток и начинается инвестиция усилий в инженерные решения, вместо инвестиций в данные (эвалы, разметки на руткоз, разметки для обучения). Это еще и полируется сверху llm-as-a-judge, и этот инженерный урборос катится куда-то в сторону от простого решения.

Что с этим всем делать? Во-первых изучать мл-систем дизайн. В арсенале инженера должно быть много инструментов решения типовой проблемы (а поиском мы уже пол века занимаемся). Во-вторых инженерные решения должны опираться на данные. Хорошо бы распричинить ошибки вашей системы на около-прод распределении, и для начала понять, а почему текущий подход не справляется? Это натолкнет на наиболее дешевое решение. Да это гораздо трудозатратнее, чем просто воткнуть модную блестящую штуку себе в пайплан, но зато и успех намного вероятнее в таком подходе.

Учим ллм мыслить по-байесовски

Попалась в новостях сегодня классная статья от гугла: ребята обучили ЛЛМпринимать решения по-байесовски просто апроксимировав политику байесовского классификатора лорой на синтетической задаче. И эта способность обобщилась на другие задачи. Причем без всякого grpo.

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

Интуиция, почему так происходит понятная: в обучении LLM совершенно нет временного измерения: вся вероятностная модель строится так, как будто модель взглянула на статический слепок данных (по крайней мере в рамках одной стадии обучения). А вот в инференсе появляется новое измерение: время. И во времени ллм начинает получать новые данные. Но при этом учиться учитывать эту новую информацию ее особенно не учат: максимум в датасете преф-тюна есть кусочек корпуса, где пользователь собачится с ллм и та исправляется.

А ребята предложили интересную идею: а давайте возьмем обычный байесовский классификатор на синтетическую задачу (а такой классификатор прекрасно умеет обновлять свое поведение с появлением новой информации) и попробуем задистилить поведение такого классификатора в ллм через преф-тюнинг. И заработало. Причем тупо на лоре, которую на ноуте бытовом можно потюнить. Ллм реально начинает и на других задачах принимать решение в байесовскои подходе.

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

Рисеч с большой буквы. Не просто заливают все компьютом, а реально свежие идеи рожают. Просто кайф.