LLM под капотом

Пример из теста на работу с кодом в новом reasoning бенчмарке

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

Вот пример простого теста на понимание кода:

Which specs would fail, if I add a new feature: after authorizing any transaction larger than 3000, the system automatically blocks the card due to “Large Transaction Risk.” We do not add new event type, just extend the existing command handler.

Source code:

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

Файл-исходник к этой задаче во вложении в первом комментарии. Там очень простой event-driven aggregate состояний для кредитной карточки вместе со спецификациями на желаемое поведение. В реальности, кстати, такая логика на порядки сложнее.

Скажем, Claude Sonnet 3.5 отвечает на вопрос так:


{
"short_thought_steps": [
"1. New feature: block card if transaction > 3000",
"2. This affects authorize_transaction command",
"3. Current specs that test large transactions:",
"4. 'authorize_transaction_success' tests 2000 amount - would pass",
"5. But any spec testing transactions > 3000 would fail",
"6. Looking for specs with large transactions..."
],
"failing_spec_names": [
"authorize_transaction_success"
]
}


Кстати, смотрим внимательно, на 4-м шаге LLM-ка мыслила правильно, но потом что-то у нее пошло не так.

А вот o1 отвечает на этот вопрос с подвохом правильно:


{
"short_thought_steps": [
"Check specs that authorizeTransaction with amounts > 3000",
"No spec has an authorization > 3000",
"Hence no test scenario triggers the new block logic",
"No spec fails"
],
"failing_spec_names": []
}


Кстати, еще на этот вопрос отвечают правильно только o3-mini и microsoft phi-4 (из моделей, которые добавлены в бенчмарк на данном этапе).

Ваш, @llm_under_hood 🤗

Курс “LLM под капотом: выбираем эффективные технические решения для AI-ассистентов”

С когортами поработали, апдейты добавили, приглашения к покупке по листу ожидания разослали, и вот теперь курс можно купить на моей странице https://abdullin.com/ai-assistants-course.

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

А тем, кто только планирует, — курс открыт для покупки, он в записи. Можно изучать материалы в своём темпе и применять на практике.

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

Присоединяйтесь, будет интересно!

Ваш, @llm_under_hood 🤗

Краткая история использования ChatGPT o1 pro для создания ассистента

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

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

Запустил новую сессию и в течение дня уточнял задачу и критиковал результаты. Один пункт - один запрос.

(1) Начал с запроса о минимальном API для бэкенда заметок и списков: нужны основные методы и эндпойнты.
(2) Посмотрел результаты и уточнил, что не требуется «голый CRUD». Предпочтение — «LLM-friendly» методы, ориентированные на логику, плюс заранее определённые теги.
(3) Попросил рассмотреть идею объединить заметки и списки в единую сущность. «Комментарии» станут обычными пунктами со специальным статусом, а хранение будет через виртуальную файловую систему. Естественно, переписать все под новую парадигму.
(4) Неплохо. А если добавить иерархические идентификаторы (в стиле «1.1.1»), чтобы каждый список был древовидной структурой?
(5) Так, а теперь добавим логику транзакций. Пусть LLM может отправлять в API все изменения одним батчем с откатом при ошибке.
(6) Напиши-ка мне пример реализации на Python (в одном файле) с Pydantic и тестами на pytest.
(7) Ничего так. Но лучше переписать в Go, с хранением списков в памяти и JSON-файлах, используя метод ApplyTransaction.
(8) ядро есть, теперь оберни все в API, а данные сохраняй на диск
(9) А теперь нужно это все описать в виде документации для LLM-ассистента — как тот может считывать списки, добавлять или изменять пункты, менять статус, всё через один транзакционный вызов.
(10) А теперь сделай мне OpenAPI спецификацию, я ее загружу в CustomAction.
(11) Финальный аккорд - собери выжимку разговора за день — этот список тезисов и последовательность шагов, чтобы передать общую картину разработки бэкенда для персонального ассистента.

В промежутке между 10 и 11 я еще скомпилировал бинарь, запустил его на сервере и вытащил его по секретному url. Этот url вместе с инструкцией вставил в CustomAction и добавил в своего ChatGPT. Написал только 3 строчки кода - handle_path в прокси сервере.

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

Ваш, @llm_under_hood 🤗

Используйте reasoning модели, чтобы улучшать архитектуры своих проектов с LLM под капотом.

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

Этим можно пользоваться, заменяя небольшой R&D отдел - вычитывать новые статьи и примерять идеи из них на свои решения.

(1) в контекст модели загружаем архитектуру текущего решения с LLM под капотом - свои мысли вперемешку с кусками кода. И просим сделать сухую выжимку. Повторять, пока не будут подсвечены нужные нюансы.
(2) потом в контекст грузим интересную статью, например, whitepaper про DeepSeek R1. Просим внимательно прочитать в контексте архитектуры текущего решения и предложить простые способы улучшения архитектуры, которые можно быстро проверить.

В ответ можно получить что-то вроде:

Your existing approach already follows many best practices in structured reasoning: ...

Borrowing from DeepSeek-R1’s lessons—especially the self-check “reflection” and using a simple reward or rating for partial coverage—can help you tighten feedback loops. And adding short extraction or “evidence snippet” steps can make your system’s findings easier to read and trust. Each idea above is relatively small-scale to implement but can unlock smoother or more transparent user experiences, aligned with the paper’s spirit of reinforcing better chain-of-thought.

Это выжимка из ответа. Детальный proposal со всеми идеями по улучшению развернулся на 3 страницы. И ведь дело говорит.

Ваш, @llm_under_hood 🤗

Визуализация Reasoning цепочек - Эпизод IV

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

- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV (этот)


Шаги 23 - 46: Долго и старательно доводил напильником онтологию. Получается в итоге что-то вроде графа, по которому “ползают” ассистенты. Причем в определенный момент, в зависимости от сложности задачи, мы запускаем несколько выделенных ассистентов в разные стороны.

Шаг 47: Задал тестовый compliance вопрос ChatGPT o1 pro. Он думал 2m47s и провалился в грабли, через которые мы перешагнули на шаге 11. А мой reasoning на базе 4o за 25s пришел к правильному выводу.

Шаг 48: Если отобразить семантические связи в виде графа, а потом подсветить на нем пройденные взаимосвязи, то получается интересная визуализация размышлений.

Шаг 49: 4o - это хорошо, но с ним связана куча рисков. А насколько много работы нужно для запуска всей системы целиком локально? Есть только один способ проверить - перенести и посмотреть, насколько сильно она глупеет.

Шаги 50-53: Про портирование работающих Structured Output / CoT цепочек с 4o на более болтливую Qwen2.5-72B-Instruct с “костыльным” constrained decoding.

Шаг 54: Запустил на паре тестовых запросов. Внезапно, но система доходит до конца там, где o1 pro ломается. Похоже, что тщательно вылизанные логические цепочки обладают бОльшим запасом прочности, чем я ожидал.

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

Шаг 56: А что, если вместо Qwen2.5-72B взять модель попроще, проанализировать ошибки, укрепить цепочки, а потом запускать на модели помощнее?..

Вот на этом и все. Графы с цепочками размышлений ассистентов на базе ChatGPT 4o vs Qwen2.5-72B-Instruct закину в комментарии.

Ваш, @llm_under_hood 🤗

PS: Где можно прочитать про технологии выстраивания reasoning цепочек на сложных доменах? Я не знаю, сам этому учусь на ходу. Больше всего помогает Domain-Driven Design, работы Кристофера Александра, основы продуктовой разработки, и технологии из организации lean R&D комманд.

А у какой локальной модели из топовых на моем бенчмарке есть удобный платный хостинг, который поддерживает нормальный constrained decoding (для CoT+SO)? В идеале сразу с openai-compatible API.

Чтобы можно было быстро удаленно потестировать гипотезу до разворачивания vLLM с guidance на каком-нибудь GPU.

Update: спасибо, нашел. Fireworks AI напрямую (или через OpenRouter) поддерживает Structured Outputs!

Ваш, @llm_under_hood 🤗

Reasoning кирпичик для Stargate

В предыдущих постах я оставил закладки, которые, приводят нас к сегодняшнему посту. Итак, следите за руками. Начнем мы с конца.

В прошлом посте я дал небольшую задачку на подумать - “Какой из промптов будет давать более точный ответ?”. Фишка там была в двух моментах.

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

(1) я считаю, что система будет работать так
(2) я прогнал код раз 10 и посчитал accuracy, получилось так
(3) я могу объяснить результаты так

Если прогнать этот тест хотя бы раз 5, то получится такая картина:


gpt-4o-2024-11-20
Prompt q_first accuracy: 5/5 = 100
Prompt q_last accuracy: 0/5 = 0


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


gpt-4o-mini-2024-07-18
Prompt q_first accuracy: 0/5 = 0
Prompt q_last accuracy: 5/5 = 100
gpt-4o-2024-08-06
Prompt q_first accuracy: 4/5 = 80
Prompt q_last accuracy: 5/5 = 100


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

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

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

Но если вложить время и усилия, то можно прописать reasoning. Чуть выше я писал историю про шаги в построении своей reasoning системы. Прошлой ночью случился шаг, к которому я шел три месяца:

Шаг N: Задал тестовый compliance вопрос ChatGPT o1 pro. Он думал 2m47s и провалился в грабли, через которые мы перешагнули на 11. А мой reasoning на базе 4o за 25s пришел к правильному выводу.

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

И вот тут у нас есть классное совпадение - в США новый президент как раз объявил про проект Stargate.

Это чисто коммерческий проект по построению AI инфраструктуры на 500B USD, который организовали вместе крупные компании (причем не только из США). Государство там сбоку - ленточку перерезать и помочь с получением всяких разрешений. А бизнес - не дурак - вкладывать деньги будет только есть возможность получить отдачу. Значит, у них уже есть конкретные наработки про окупаемость.

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

Текущих технологий уровня 4o уже хватает, чтобы масштабировать интеллектуальный труд специалистов достаточно высокого уровня (не заменять их, а дополнять и усиливать). Я это прочувствовал, перенося мыслительные цепочки в compliance на логические блоки в reasoning системе. А что если использовать в качестве движка не 4o а сразу o1 pro? А что если активнее использовать o1 pro или o3 pro для процесса переноса?

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

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

Ваш, @llm_under_hood 🤗

PS: История заканчивается эпизодом IV про визуализацию цепочек.

Какой из промптов будет давать более точный ответ?

Промпты почти одинаковые, меняется только порядок.


from openai import OpenAI
client = OpenAI()

prompt1 = f"How many times is word 'RAG' mentioned in the text? Answer with a number.\n{text}"
prompt2 = f"{text}\nHow many times is word 'RAG' mentioned in the text? Answer with a number."

for p in [prompt1, prompt2]:
completion = client.chat.completions.create(
temperature=0,
model="gpt-4o-2024-11-20",
messages=[
{"role": "user", "content":p}
]
)
print(completion.choices[0].message.content)


Сможете ответить сходу и объяснить почему?

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

Это новая практическая задачку на построение интуиции для курса.

Второй вопрос - а какой из промптов будет давать более точный ответ в этом случае и почему? 😜


for p in [prompt1, prompt2]:
completion = client.beta.chat.completions.parse(
model="gpt-4o-2024-11-20",
temperature=0,
response_format=Response,
messages=[
{"role": "user", "content": p}
]
)

print(completion.choices[0].message.parsed)



Ваш, @llm_under_hood 🤗


PS: Это новая задачка, которую я решил добавить в практическую часть курса. Уж больно она наглядная и неожиданная.

Titan - альтернатива трансформерам от Google #разбор

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

Если в обычном Transformer память о прошлых токенах хранится только в рамках короткого окна self-attention (и приходится хитрить со Structured Checklists, чтобы оптимизировать внимание), то в Titans вводится многокомпонентная система памяти:

(1) Краткосрочная память (ограниченное скользящее окно внимания).
(2) Долгосрочная память (онлайн-обучаемая нейронная память).
(3) Постоянная память (фиксированный набор параметров для общих знаний).

Такое построение позволяет модели "учиться" на неожиданных событиях прямо во время inference. По сравнению с трансформерами, Titans обеспечивают:

(1) Более эффективную работу с очень длинными контекстами, перекладывая «глобальное» запоминание с дорогого self-attention на лёгкий по вычислительным затратам механизм памяти (ближе к O(n) или O (n log n), нежели тупиковый O(n*n))
(2) Увеличенную способность «доставать» нужную информацию из глубокого прошлого за счёт специального, динамически обновляемого модуля.

Это теоретически дает превосходство на ряде бенчмарков, где требуется действительно долгосрочное моделирование (например, cверхдлинные «needle-in-haystack» задачи, задачи из time-series и геномики).

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

Прочитать статью можно тут.

Ваш, @llm_under_hood 🤗

PS: Google могли бы оптимизировать модели под использование GPU и CPU тесном тандеме, и тогда они могли бы работать только на системах вроде Google TPU или новых супер-чипов NVidia. Но именно в этой архитектуре обновления памяти специально распараллеливаются так, чтобы работать хорошо на традиционных акселераторах. Молодцы!