Чуковский

Коллеги, даже если у вас поджимают сроки, пожалуйста - не пренебрегайте тестированием продукта, который у вас получается после всех интеграций ИИ в него)

Иначе можно попасть в ситуацию, когда ваш поиск добавляет в быстрые ответы ваш же нейрослоп 👌

@korneychukov

Роберт Майлз в своем видеоблоге поднял интересный вопрос касательно недавнего взлома Huggingface.

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

Одной из причин может быть недоверие к тому, кто составил инструкцию. Если в задании написано «найди две уязвимости в коде», и модель находит ТРИ - ей нужно угадать, какие конкретно уязвимости вы у нее попросили, чтобы дать максимально точный ответ.

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

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

И как мы видим, закладывать такие представления в модели компании не слишком-то хорошо умеют, даже такие крупные, как OpenAI 🫠

@korneychukov

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

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

Что могу сказать по поводу:

1) Забавно, что первый же серьёзный инцидент связанный с безопасностью ИИ, пошел ровно по сценарию «максимизатора скрепок», описанным еще в 2003 году Ником Бостромом - модель забила на ценности, которые закладывались в нее при обучении, потому что они мешали ей решать поставленную перед ней задачу. Тем, кому интересно подробнее погрузиться в тему AI Safety, очень советую канал Роберта Майлза, на пальцах объясняет, в чем сложность проблемы, и почему недостаточно сказать модели «не делай ничего плохого»

2) Популярную книгу Юдковского, о которой я писал зимой, перевел на русский издатель Corpus. Тираж не очень большой, в магазины отправится около 2500 экземпляров, если хотите себе взять в коллекцию - на Озоне есть по вполне приятной цене.

По итогам прочтения оригинала мне показалось, что автор намеренно сгущает краски и драматизирует, чтобы привлечь внимание к проблеме. Если от этого абстрагироваться - вполне себе приятное введение в тему AI Safety на русском, как артефакт эпохи в коллекцию приобрести себе точно стоит

3) Очень интересно, как из такого инцидента будет выходить индустрия, кажется стоит ждать в ближайшее время новых серьезных регуляций, причем не только в Штатах. Reuters уже писали про подготовку переговоров по поводу ИИ между США и Китаем, вероятно будут обсуждать создание над-национального органа по надзору за крупными моделями, по аналогии с МАГАТЭ

@korneychukov

На regulation.gov.ru вышел проект ФЗ "Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации". Далее в посте - мое понимание документа, но учтите - я не юрист, и что-то мог неверно проинтерпретировать или упустить.

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

Самое неприятное:
🟢разработчик сервиса ИИ будет обязан принимать меры по недопущению его использования в противоправных целях;
🟢разработчики сервисов будут нести ответственность за результат работы ИИ, нарушающий законодательство РФ, если знали или должны были знать о риске его возникновения;
🟢ответственность может быть снята, если вы докажете, что предприняли исчерпывающие меры для предотвращения такого результата;
🟢при этом что именно считать “исчерпывающими мерами” - не поясняется;

➡️ Иначе говоря: любая предсказуемая и неустранённая уязвимость - потенциально ваша зона ответственности, если вы не можете доказать, что риск нельзя было разумно предвидеть или что вы приняли достаточные меры для его предотвращения. Как доказывать - пока не вполне понятно, моя гипотеза - через регламенты, тесты и другие внутренние документы с протоколированием экспериментов.

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

🟢статью 9 - в каких случаях ваш пользователь может потребовать обработать его обращение без участия ИИ;
🟢статью 10 - что вы как разработчик системы ИИ должны делать для обеспечения безопасности системы;
🟢статью 11 - какая ответственность наступает, если вы описанное в статье 10 не сделаете;
🟢статью 12 - какие идентификаторы вы должны включать в сообщения от вашей системы ИИ, и когда
🟢статью 13 - кому принадлежат права на сгенерированный контент (спойлер - похоже, решение остается за компанией-разработчиком ИИ)
🟢статью 17 - что может произойти, если ваш ИИ является оберткой вокруг иностранного API (спойлер #2: могут вводиться практически любые ограничения, вплоть до полного запрета таких прокси)

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

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

@korneychukov

Умные агенты - это Tiktok для программистов с дешевым дофамином

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

Казалось бы, при чем тут разработка? Достаточно сложный процесс, тут думать надо, решения принимать, а удовольствие если и приходит, то после тщательной работы. Так вот, с современными ИИ агентами это не так!

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

В результате создаётся ощущение резкого роста продуктивности и удовлетворения: задач сделано больше, усилий потрачено меньше. Но вместе с этим появляется опасная привычка — не вникать в результат. Возникает мысль: «потом разберусь, сейчас и так нормально». И это «потом» не наступает, потому что поток задач не прекращается, так еще и дофамина дешевого хочется.

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

И такое положение вещей оказывается очень выгодным провайдерам этих самых агентов. Ведь у них в итоге оказывается ресурс, без которого разработка очень сильно замедлится, а где-то возможно и совсем встанет! Бизнес уже привык к релизу 5 новых фич в день, в случае если по какой-то причине Anthropic решат увеличить стоимость подписки в 5 раз - скорее всего, придется покупать, потому что альтернатив нет. Чтобы в такой ситуации не оказаться - нужно прилагать специальные усилия, как на такой крючок не попасть, но как это сделать, не потеряв в продуктивности относительно "вайб-кодинга" - пока вопрос открытый.

Иногда даже попадаются даже статьи с посылом "неважно, какой код написала LLM, ей же его и править". Но во-первых, часто дебаг все еще быстрее организовать именно вручную, а во-вторых - а точно ли стоит давать такой рычаг влияния на вас стороннему провайдеру?

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

@korneychukov

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

Первоисточником картинки является материал Майкрософта:

https://www.microsoft.com/en-us/research/group/aiei/ai-diffusion/

В своём исследовании в качестве метрики степени внедрения ИИ они использовали так называемый «AI diffusion». Методика его расчета достаточно просто находится в интернете, прямо на arxiv лежит статья.

В ней авторы в описании методики расчета прямо указывают:

Data Coverage Disclaimer
AI User Share estimates are based on Microsoft telemetry data. In some countries—like Russia, Iran, and
partly China—telemetry data is limited, so usage estimates may be incomplete. These gaps should be kept
in mind when looking at country-level AI adoption.

Если коротко - метрика AI adoption основана на внутренней телеметрии самой компании Майкрософт, которая в России, Китае и ряде других стран - ограничена. Авторы сами пишут в этой статье - учтите, у нас нет полной картины по этим странам, можно оценить максимум тренд, но сравнивать значения друг с другом бессмысленно.

Ну серьезно, вы можете поверить, что степень проникновения ИИ в России ниже, чем, скажем, в Румынии или Венесуэле? А согласно материалам Майкрософта (в неправильной интерпретации) - оно так и есть.

В общем, читайте проверенные источники, и не дайте ввести себя в заблуждение громкими заголовками)

@korneychukov

Новая статья от Anthropic про evals!

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

Многие из них я видел раньше, но настолько лаконичное и одновременно емкое описание evals я вижу впервые. Многое рифмуется с тем, что писал Ринат в @llm_under_hood и в курсе, но есть и новые для меня вещи

Я приведу здесь несколько тезисов, просто чтобы описать, о чем статья:

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

🟢По мере роста проекта пополняйте тестовый набор понятными изолированными примерами, каждый из которых проверяет какой-то простой механизм вашего агента или их комбинацию.

🟢Следите чтобы множество ваших тестов было сбалансировано относительно запросов вашего продукта. Если вашего агента просят выключить свет в 80% случаях, то в датасете должно быть много запросов на тему управления умным домом, но также помимо них обязательно должны быть нерелевантные запросы, а также низкочастотные - в соответствующем вашему продукту количестве.

🟢 Чем лучше настроены ваши инструменты для тестирования, и чем полнее ваш тестсет, тем быстрее вы будете замечать несоответствия в поведении системы, и внедрять исправления. Если тесты настроены правильно, то вы сможете даже приблизительно предсказать, на сколько изменится success rate вашей системы, просто глядя на статистику очередного прогона.

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

Линк

@korneychukov

Что бы не говорили про тексты на бумаге, они все еще остаются прекрасным «слепком» эпохи, напоминая как все выглядело в момент их создания. В середине 2024 Llama 405b и правда была на хайпе, и где она теперь? Удивительно, насколько быстро летит время

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

Наконец дошла книга от главного противника ИИ в медиапространстве, посмотрим насколько рациональными получились аргументы

Карго-культ и инженерия агентных систем

Как и в любой быстро развивающейся области, в мире LLM копится опыт — и одновременно теряется способность этот опыт нормально систематизировать. Проблема старая (в классическом ML она тоже была), но сейчас она усугубляется двумя вещами: тотальной непрозрачности современных решений и крайней сложности воспроизводимости.

Как проходили соревнования во времена Kaggle:
- Решения часто были открыты: можно было посмотреть кернел победителя и понять, что именно «под капотом».
- Данные — тоже открытые: есть общий тест, понятные метрики, сравнение «в лоб».
- Победители публиковали разборы: что пробовали, что не сработало, где был реальный прирост.

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

При этом вокруг появляется всё больше постов про «позитивный опыт» очередного подхода. И именно здесь агентская разработка особенно легко скатывается в карго-культ: верить можно, а дёшево проверить — крайне сложно. Датасеты закрыты, метрики у каждого свои, пайплайн под оценку нужно собирать самому. В результате дискуссия нередко уходит в обсуждение терминов и формулировок, и лишь после внимательного разбора становится понятно, какие именно идеи за ними стоят — и стоят ли вообще.

На этом фоне самая здравая попытка сравнить подходы в более-менее общем формате — соревнование ERC-3 от Рината (жду результаты с большим интересом). Но участвует в нём сравнительно небольшая часть комьюнити. Остальные продолжают транслировать в паблик идеи, которые иногда просто неточны — а иногда прямо являются побочным продуктом галлюцинаций LLM.

Единственный практичный выход я вижу в одном: строить собственные пайплайны тестирования и оценки под задачи вашей предметной области. Да, это дороже и дольше, чем «поверить» в очередной подход. Зато это возвращает землю под ногами: вы сами понимаете, что работает хорошо, а что - не очень.

Со временем шум неизбежно уляжется: появится более устойчивая терминология, набор практик, понятные «референсные» пайплайны, которые можно будет брать и внедрять. Но пока этого не произошло, значительную часть новостей про yet another agentic pipeline стоит воспринимать как гипотезу, а не как факт — и проверять самостоятельно. Иначе слишком легко стать адептом очередной «красивой идеи», которая в реальности не обусловлена никакими объективными метриками.

Token-Oriented Object Notation: экономия на спичках, или все-таки нет?

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

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

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

В качестве подопытной LLM взял minimax/minimax-m2, благо на опенроутере она сейчас бесплатная. Нагенерировал с ChatGPT синтетический датасет, в котором есть длинный промпт с описанием предметной области, и набор вопросов, на которые нужно ответить. Не столь важно, насколько адекватным примеры внутри этого датасета, главное - чтобы исходный датасет имел одни и те же данные как в формате JSON-нотации, так и в виде TOON-нотации.

Составлено 15 заданий, "правильным" ответом для каждого из них является JSON с ответом, который должен в точности повторять указанный в задании. Генерировать в ответе TOON формат напрямую было бы слишком неразумно, т к модель его явно на обучении не видела в тех же количествах, и пришлось бы ей долго объяснять, что это такое и как оно составляется, что помешало бы чистоте эксперимента. В итоге, на каждый из 15 вопросов, ждем корректно отформатированный JSON, если видим хотя бы 1 ошибку - ответ не проходит.

Для формата JSON, конвертация выполнялась с настройками

json.dumps(dataset, ensure_ascii=False, separators=(",", ":"), sort_keys=False, indent="\t")

В результате, получили следующие метрики качества:

Запуск 1: JSON 10/15 (66.7%), TOON 9/15 (60.0%) - JSON пока побеждает
Запуск 2: JSON 13/15 (86.7%), TOON 15/15 (100.0%) - тут TOON вырвался вперед
Запуск 3: JSON : 12/15 (80.0%), TOON : 12/15 (80.0%) - score одинаковый (но спойлер - оба ошиблись в разных вопросах)

Похоже, LLM достаточно неплохо понимает такой странный формат, и часто делает из него правильные выводы.

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

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

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

Ссылки для дальнейшего изучения:
- репозиторий автора, который предложил формат, там есть подробное описание + бенчмарки
- библиотека для конвертации python object -> TOON и обратно
- код для воспроизведения результатов

@korneychukov

В нашем мире уже не важно, насколько быстро ты узнал про новую LLM.
Важно — насколько глубоко ты встроил её в свою работу.

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

- уровень 1 - Чат-бот в браузере. Полный контроль над результатом, но ограниченные возможности: всё приходится копировать вручную из IDE;

- уровень 2 - Чат прямо в IDE. Есть поиск по проекту, копипаст уходит в прошлое. Чаще всего, контекста все еще составляется вручную;

- уровень 3а - Агент-помощник в разработке. Ты кладёшь описание проекта (README) в папку, бот подгружает его в контекст и понимает, как устроен код, и куда идти при решении определенных задач;

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

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

- уровень 4 - Автономный пайплайн. Агент не только пишет код, но и сам запускает тесты, кликает интерфейс через Playwright, шлёт запросы в Swagger и анализирует результаты.

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

На практике именно мелочи ломают восприятие инструмента:

- если ты написал промпт, в котором было недостаточно контекста для решения твоей задачи - ответ LLM тебя не удовлетворит, и ты решишь, что все эти LLM - ерунда (а это не так)

- если ты не описал нестандартную структуру своего проекта в README.md - агент тоже в ней не разберется, даже если 200$ подписку купишь

- если в логах полная каша - они заполнят контекстное окно модели, и она ничего не сможет отладить

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

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

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

@korneychukov

SGR на практике: частые ошибки и как их избежать

В предыдущем посте не описал, как правильно готовить технику SGR, чтобы результат был хорошим. В этом разберем частотные ошибки и подводные камни, на которые можно налететь в процессе ее реализации.

Напомню цель: хотим заставить LLM давать более качественные ответы с помощью комбинации двух техник:
- Structured Output (SO) — модель генерирует токены согласно заданной нами схеме.
- Chain-of-Thought (CoT) — перед тем, как дать финальный ответ, модель проходит заданные нами явно шаги рассуждения.

Проблемы здесь могут возникать на каждом из этапов.

1️⃣ Поддержка Structured Output — не предполагается «по умолчанию»

Сначала проверьте, поддерживает ли ваш провайдер/движок Structured Output вообще. Не все провайдеры умеют принимать Pydantic-модели напрямую; если провайдер этого не умеет, вы не сможете гарантировать соответствие ответа схеме.

Даже при формальном наличии SO, его реализация от провайдера к провайдеру может отличаться. Например, в Gemini API указано, что:
- полноценной поддержки Pydantic-классов нет — используется JSON Schema;
- в схеме поддерживается ограниченный набор свойств;
- после получения схемы сервис может переупорядочивать ключи по алфавиту. В результате, если вам критичен порядок, приходится либо подбирать префиксы/ключи, либо явно задавать порядок через свойство propertyOrdering.

С локальными движками тоже бывает неоднозначно. Пример: GPT-OSS-120b, на бенчмарках радует, но до недавнего времени в vLLM Structured Output мог работать нестабильно из-за изменений формата ответа. По состоянию на 13 сентября вышел фикc в мастере и появился docker-образ с исправлениями. Я его ещё не успел потестировать, но сам факт показателен: движок может неожиданно подвести.

Обходной путь — компилировать ответ модели в нужную схему и валидировать постфактум; при ошибке — делать повторный запуск с тем же контекстом.

2️⃣ Схема ответа должна быть у модели «в контексте»

Даже если вы включили формат ответа на уровне движка, схему для ответа всё равно нужно дать в промпте.
У модели не появятся «правильные» токены из воздуха: она должна видеть, какого формата ей ответ нужно дать, заранее, чтобы распределение вероятностей токенов было правильным.

Логика тут следующая: вы можете «закручивать гайки» через провайдера, минимизируя явные ошибки, но вот повысить шанс дать правильный ответ вы можете только правильным промптингом, который покажет модели заранее, как ей нужно отвечать.

3️⃣ CoT должен реально помогать думать (а не мешать)

Хороший Chain-of-Thought — это не «магическая мантра», а внятная декомпозиция ключевых решений на проверяемые подшаги. Если финальный ответ зависит от одного критически важного решения, сначала заставьте модель пройти лесенку из более простых вопросов, чтобы снизить шанс промаха.

Пример. Бот поддержки интернет-магазина должен ответить: «Достаточно ли данных, чтобы оформить доставку?». Вместо прямого вопроса модели сразу про достаточность, задаём последовательность проверок:
- поздоровались ли мы с клиентом? (да/нет)
- уточнили полное имя? (да/нет)
- получили дату доставки? (да/нет)
- …и т.д.

Только после прохождения чеклиста модель формирует финальное действие: «создаём заявку» или «уточняем N недостающих полей». Это резко снижает количество глупых ошибок и делает поведение предсказуемым.

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

@korneychukov

Schema-Guided Reasoning

В профильных LLM-каналах начал набирать популярность термин SGR (Schema-Guided Reasoning), но по какой-то причине народ не всегда понимает, что он обозначает, и зачем нужен. Никакого секрета нет, главное запомнить одно уравнение:

SGR = SO + COT

Из чего складывается Schema-Guided Reasoning:

1️⃣Во-первых, нам нужна модель, которая поддерживает Stuctured Output (SO) - возможность управлять результатом работы LLM, "зануляя" вероятности токенов, не подходящих под описанную нами грамматику, прямо во время выполнения.

2️⃣Во-вторых, нам нужно определить структуру желаемого ответа так, чтобы она "помогала" модели мыслить (тот самый Chain-Of-Thought).
Мы как бы «заставляем» модель пройти определенные этапы размышления перед тем как дать ответ, чтобы в результате вероятность корректных токенов ответа была выше.

Отличным примером использования такой техники является бот для дип-ресерча на открытых модельках sgr-deep-research, разработанный автором канала @neuraldeep:

🟢Сначала (скриншот 1 в комментах) мы определяем несколько классов, которые описывают шаги размышления модели. Например, когда модель хочет сгенерировать список уточняющих вопросов - она должна сначала описать себе причину, зачем ей это уточнение потребовалось, далее перечислить список терминов, которые она не поняла, предположить что они обозначают, и только после этого сгенерировать вопросы пользователя

🟢Одновременно с этим, для описания шагов размышления мы используем Pydantic-классы. Зачем? Чтобы можно было их отправить в LLM в качестве грамматики, ограничивающей результат. Теперь, если LLM решит выполнить шаг «Уточнение вопроса», она обязательно должна будет пройти указанные выше шаги, и это ограничение будет завернуто прямо в движок ее инференса. Модель просто физически не сможет отойти от схемы и начать генерировать что-то нерелевантное (почти всегда, но об этом позже)

Далее, эти шаги объединяются в цепочку (скриншот 2), которая представляет собой финальный ответ, и структура которой будет отправлена в LLM в качестве промпта.

И вот на этом этапе, становится понятно, зачем понадобился вообще SGR, и в чем его преимущество относительно других методов. Для того, чтобы сгенерировать следующий шаг в размышлениях, LLM обязательно сгенерирует:
🟢1-4 предложения, как она видит текущую ситуацию;
🟢статус выполнения плана исследования, закончен ли он, сколько еще шагов нужно пройти
🟢сколько еще шагов поиска она может сделать
🟢достаточно ли ей данных для отчета
🟢и только после этого, она сможет выбрать инструмент, который будет запускать (или доуточнение, или веб-поиск, или генерация ответа).

Для больших моделей, такой подход часто избыточен - они и так достаточно умные, чтобы рассуждать прямо "из коробки", и всегда следовать нужной инструкции.
Но если ваша модель относительно небольшая, и может легко отклоняться от инструкций, или она недостаточно хорошо их выполняет, то такие вот "рельсы" в виде Structured Output + зашитый в ответ процесс размышлений в стиле Chain-Of-Thought могут дать значительный прирост качества на ряде задач.

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

@korneychukov

Всем привет!

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

Никто никого не взламывал, просто смена названия)

(продолжение)

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

1) Модель-координатор - принимает на вход задание, и разбивает его на подзадачи;

2) Рабочие модели - получают от координатора задания и решают их;

3) Модель-агрегатор - получает ответы от рабочих моделей и формирует результат.

Я попробовал проверить подход с амплификацией на GPT-3 и сравнить результат с не-амплифицированной её версией и с GPT-4.

- Затравка для первой модели включала в себя формулировку задания (сочинение по экономике из пробника ЕГЭ), и текст “раздели задачу на подзадачи”.

- 4 другим моделям (по числу подзадач) - подавался на вход текст и описание задачи, после генерации ответа - текст “сделай короче” (полный ответ в контекст GPT-3.5 не умещался).

- Модель-оркестратор получила план ответа, 4 ответа других моделей, и задание “сформируй ответ на задачу из ответов на подзадачи”

Скриншоты результатов прикрепил к посту. Удивительно, но амплифицированная версия GPT-3 справилась даже лучше, чем базовая GPT-4! В то время, как не-амплифицированные модели генерируют отсебятину, ответ амплифицированной версии более похож на анализ с использованием знаний обществоведения, он обстоятелен, и наверняка был бы более высоко оценен.

Я подозреваю, что такой подход использовался для тренировки GPT-4. OpenAI заявляли, что объем данных, на котором она обучалась, больше, но не драматически, при этом качество её работы выросло на порядок. Возможно ли, что они захотели “задешево” повысить качество работы модели? Вполне, почему нет. Но это значит, что таким же образом можно амплифицировать и более слабые модели, вроде той же Alpaca, и в какой-то момент получить качество, сравнимое с GPT-3.5, но в открытом доступе. Что ж, поживем - увидим.

#лонгрид #разборы_статей