Ручка и блокнот - превосходно работают для управления агентами

Процесс выглядит так:
- берем чашечку кофе
- пишем идеи в блокнотике в приятном месте
- парсим текст при помощи ChatGPT
- отправляем AI+Coding агенту
- делаем ревью и деплоим
- помечаем Done
- допиваем чашечку кофе

Ваш, @llm_under_hood 🤗

Кейс про reasoning, в котором автор признается в использовании векторов и в архитектурной ошибке

Задача кейса - ускорить работу c документами compliance офицеров, час работы которых стоит 160-400 EUR и выше.

Я про это уже писал тут:
- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV

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

Система состоит из трех частей.

Первая часть - data parsing с VLM под капотом. Регуляторные документы обычно распространяются в хитровыверченных PDF разных форматов. Нам нужно не просто их распарсить в текст, но и сохранить семантическую структуру (граф).

Когда я показал один такой документ Илье, он сказал про “криптонит всех парсеров” и “коварно” 😁

На эту часть я потратил в сумме три месяца. Под капотом - PyMuPDF, Paddleocr/PaddleX, Gemini Pro 2.5/OpenAI и пара интерактивных интерфейсов для реализации REPL/Human In The Loop. Конечно же SO CoT.

Вторая часть - анализатор документов c LLM под капотом. Это workflow, который сопоставляет набор регуляторных документов и набор внутренних документов, выделяет список применимых требований и аргументированно выдает список проблем во внутренних документах, которые надо бы проверить.

На эту часть я потратил тоже месяца три в сумме.

(1) загружаем все релевантные графы документов
(2) проходимся по графам, анализируем узлы, проецируем все в мини-графы. Каждый мини-граф - это конкретная статья со всеми подпунктами и релевантным контекстом
(3) анализируем каждый мини-граф - содержит ли он в себе конкретные требования, которые нужно выполнять? А применимы ли эти требования к рассматриваемым документам?
(4) анализируем найденные требования - критичность? какая информация должна быть во внутренних документах, которые будут эти требования выполнять?

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

(5) ищем релевантные мини-графы во внутренней документации. В текущей версии использую embedding openai-text-large + LLM review, который делается просто и из коробки работает хорошо. Если соберется достаточно размеченных данных, которые показывают на ошибки, заменю на поиск по графу и онтологиям.

(6) собираем пакет документации (мини-графы требований и найденный evidence) и прогоняем еще через один SO CoT для финального анализа. Выписываем результаты в audit report, сортируем по срочности.

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

Третья часть написана на next.js/React/Tailwind/TS + NixOS/Caddy deployment. Я на нее потратил в сумме часов 18 и пару недель. 100% кода написано AI+Coding.

Концепцию UX помог сформировать Gemini Pro 2.5 (пригодился его инженерный склад ума и активный контекст в 500k). Красивый интерфейс набросал Claude Opus 4

OpenAI Codex встроил этот интерфейс в чистый next.js шаблон и вел разработку дальше (вот тут и была моя архитектурная ошибка - next.js был очень неудачным выбором для AI+Coding - мало документации и слишком часто его меняют).

От меня агентам шел поток задач и отзывов. Они - ваяли. Использовали AICODE- память для посланий друг другу. В сложных случаях использовал implementation plan. Всегда запускал 2-4 версии задач, выбирал самый симпатичный вариант, остальные выкидывал. ~60% задач были отправлены с телефона)

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

Ваш, @llm_under_hood 🤗

Почему в канале тихо? Слишком много AI!

Помните, в ноябре прошлого года мы запускали акселератор AI проектов с Меллиферой (ныне Colibrix)?

Много всего случилось с того момента: прошел отбор подавшихся стартапов, прошли разнообразные мастер-классы и отработка навыка презентаций, организация раунда на Мальте. Этой весною жюри на Мальте отобрало один стартап-финалист - Homai, который сегодня презентовал в Женеве на глобальном саммите AI for Good от ООН.

В финал стартапу нашего инкубатора пройти не получилось, из 11 компаний дальше пойдут только 4 проекта c AI под капотом:

1. Слепой мужчина, который делает робота-поводыря для слепых
2. Анестезиологи, которые делают девайс для госпиталей
3. Женщина, которая диагностирует проблемы питания в Индии (миллионы детей уже проанализировали)
4. И женщина, которая делает девайс для послеродовых проблем детей в Африке

Но на этом Женева для Homai не заканчивается - надо стоять на стенде, презентовать идею всем заинтересованным и максимально раскручивать ситуацию для себя. Там и инвесторы, и AI компании со всего мира (очень много робототехники) и просто интересующиеся.

Поздравляем команду Homai! На этом тот первый инкубатор можно, наконец, считать закрытым.

Ваш, @llm_under_hood 🤗

И об OpenAI Codex: я в нем сейчас переписываю часть очень старой ERP системы прямо с сотового телефона (про кейс см тут, тут и тут).

Это происходит прямо на саммите AIFG в Женеве, одновременно с анализом зависимостей, миграцией БД и написанием тестов. Трачу где-то пару минут внимания каждые минут 20-25 😁

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

Получается забавный факт, что архитектура системы для полуавтоматического переписывания кода - основывается на обычных принципах построения систем с LLM под капотом - Knowledge Base, REPL и Workflow. И для стабильной работы всего этого достаточно небольшого пригляда человека (Human in the loop), который выражается в просмотре приходящих pull requests, выборе самого симпатичного и отправки заново команды:

Implement tests and code for the first non-closed gap from plans/002-v2-missing-features.md. Mark closed gaps with “DONE:”

И оно пока работает вполне себе хорошо - я сегодня уже 18 PRs закрыл.

Ваш, @llm_under_hood 🤗

Что думают про перспективы продуктов с LLM под капотом в крупнейшей в мире консалтинговой компании?

Я задал такой вопрос представителям Deloitte. А ещё DLA Piper (4k адвокатов в 40+ странах) и China Telecom.

Получается интересная картина. В применимости и ценности AI систем не сомневается уже никто. Компании сыплют кейсами успешного применения то тут то там - в бизнесе, корпорациях и промышленности. Говорят, что не видели невозможных кейсов. Триллионые инвестиции в AI как бы намекают на перспективы.

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

DLA Piper говорит про то, что основная проблема внедрения - это то, что пользователи упираются, боятся или просто не хотят осваивать новые инструменты. На каждый доллар затрат на разработку продукта с LLM под капотом нужно потратить ещё 5 долларов на его внедрение и change management. Обучать, успокаивать, адаптировать процессы итп.

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

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

Вот вам 100к USD за технологию с LLM под капотом, а вот еще 350к USD за то, что вы эту технологию у нас развернете так, что сотрудники будут её по факту использовать и генерировать тот самый обещанный 10x прирост производительности.

Все хотят получить 100k USD, но мало кто согласен еще и взять обязательные 350k.

И только China Telecom не парится по поводу проблем с внедрением: «у нас государство спускает программу сверху, и все обязаны KPI выполнять».

Ваш, @llm_under_hood 🤗

Качество - это траектория

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

Сталкивались с таким, когда допиливали своего агента, копилота или продукт с LLM под капотом?

Как я уже рассказывал, на этой неделе я был на саммите AI For Good ООН в Женеве. Через многие доклады и мастер классы красной линией проходила такая мысль:

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

Эту статистику подтверждает и Asmaa EL Andaloussi
(Lead Enterprise Strategist & Architect из Леново) и Julien Weissenberg (AI Advisor в World Economic Forum).

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

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

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

В общем, продуктов с LLM под капотом есть тьма. Любой студент может навайбкодить что-то правдоподобное на LangChain, векторной БД или паре промптов. Иногда оно даже будет работать.

Что отличает реально работающие продукты от поделок - возможность оценивать качество и планомерно его улучшать. Ведь quality is a trajectory.

Ваш, @llm_under_hood 🤗

Вот такой вот пайплайн вырисовывается в системе для миграции легаси ERP системы без тестов на современный стэк (описание кейса).

Если точнее, это выглядит как агентский пайплайн для написания тестов на основе работающего кода и ручного поиска багов. А уж переписанный код - это побочный эффект.

В основе - набор из 5-х паттернов:

(1) RAG - нарезаем исходный код на логические блоги и выстраиваем взаимосвязи между ними. Это позволит потом “хирургически точно” наполнять контекст для разных задач.
(2) Workflow - используем несколько прописанных заранее процессов, которые пошагово анализируют код, выявляют пропущенные требования (gaps), составляют планы по реализации и выполняют их.
(3) AI+Code Memory (новый паттерн, cм тут) - агенты могут оставлять друг другу заметки и комментарии, которые по определенным правилам ссылаются на другие файлы и старый код.
(4) REPL / Feedback Loop - основной автоматический процесс, который пополняет набор тестов и поправляет код до полного прохождения всех тестов.
(5) Human in the loop - человеческий пригляд используется для корректирования всей этой системы, чтобы качество тестов и кода постепенно росло. Качество - это траектория.

Ощущение от работы всей этой системы на текущих этапах непередаваемые. Словно управляешь небольшим автоматизированным заводом.

Ваш, @llm_under_hood 🤗

PS: Это не полностью автоматизированная система. Пока приходится много однообразно кликать мышкой и копи-пастить между окнами. Если проект взлетит - автоматизируем полностью.

Кейс про миграцию сотни старых MS Access файлов

Ринат, а ты можешь показать, как полу-автоматически перетащить сотни дремучих и разнообразных MS Access баз на современный стэк? Не важно какой стэк, но гарантируя качество. Тут есть компания (60k сотрудников, 100+ лет, €8B Revenue), которая никак не может найти себе подрядчика на эту задачу.

Вот такой примерно кейс позвонил мне час назад, после знакомства с результатами и процессами работы Code Factory для Legacy ERP.

И вырисовывается картина, что и этот кейс вполне себе подъемный. Причем масштаб не имеет такого значения, если поставить процессы так, что основную работу делают агенты, а люди выполняют роль Human in the Loop надзирателей.

Эта концепция Code Factory мне очень нравится тем, что она хорошо ложится на принципы теории ограничений и на основы работы высоконагруженных распределенных систем и просто на принципы работы симулятора заводов Factorio. Везде есть очереди, WIP, процесс оптимизации качества и пропускной способности системы.

И вот интересно, насколько процессы работы с AI+Coding (в больших масштабах) будут применимы к процессам автоматизации типовой человеческой работы тоже в больших масштабах? Что-то подобное я видел в автоматизации процессов оцифровки языков у Homai, где прирост производительности настолько большой, что разом выводит все на принципиально иной уровень.

Но будет интересно посмотреть, сможет ли эта концепция AI Factories проявить себя в более традиционном бизнесе. Что вы думаете?

Ваш, @llm_under_hood 🤗


PS: Если кажется, что перенос из одной БД в другую - это очень просто, не забывайте, что MS Access только притворяется БД. У него под капотом еще есть:

- дизайнер форм и отчетов
- макросы и автоматизация, VBA скрипты
- Query designer
- возможность упаковать это все в приложение-файл-БД, с менюшками и своими интерфейсами
- event-driven интерфейсы

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

Поэтому ради эксперимента завел завел отдельный канал - про AI+Coding в дискорде, на английском. Зайти можно тут https://discord.gg/YWgbqZaUnU

Ваш, @llm_under_hood 🤗

График точности всех RAG экспериментов из ERCv2

Напомню, что в Enterprise RAG Challenge 43 команды ставили эксперименты по построению RAG систем, которые смогут дать наиболее точные ответы на 100 вопросов по 100 PDF (публичные отчеты компаний). Некоторые вопросы требовали сравнительной работы с разными PDF.

Всего было поставлено 134 эксперимента с разными моделями и архитектурами. На этой таблицы они все отображены.

- R - это точность работы Retrieval алгоритма (системы должны были подтверждать свои ответы ссылками на страница)
- G - это точность финального ответа, на основе ground truth данных
- Зеленая линия - линия, где у систем качество Retrieval совпадает с качеством Generation.

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

Те, кто был ниже - находили правильные данные, но путались с генерацией ответа.

Самые лучшие RAG системы (по итоговому качеству ответов) - "сгрудились" рядом с этой зеленой линией - строго под ней. Получается логический вывод - качество финального ответа обычно зависит от качества заполнения контекста.

А в какой части этого графика оказались ваши эксперименты?

Ваш, @llm_under_hood 🤗

PS: Исходную таблицу можно увидеть на странице ERC. Там же есть ссылки на все доступные исходные данные соревнования, включая алгоритм оценки результатов и описания архитектур.

3+1 причина использовать Structured Outputs

Без Structured Outputs (SO) у меня не обходится ни один проект. Если кратко, то SO позволяет задать точную схему, по которой LLM будет отвечать. SO поддерживается всеми современными провайдерами и движками для запуска моделей локально.

Это полезно по 3+1 причинам (последняя - самая главная):

(1) когда модель отвечает числом или приводит ссылки, больше не нужно парсить ответы модели регулярными выражениями, чтобы извлечь нужные данные. Меньше кода, меньше возможностей у модели запутаться в форматировании и меньше ошибок.

(2) поскольку модель будет отвечать по схеме, мы можем прямо в схеме прописать последовательность шагов. Например, всегда сначала смотреть на заметки к таблице (“все цифры в тысячах евро”), а потом уже извлекать данные.

(3) Можно паковать в схемы множество таких логических шагов за раз, выполняя очень мощные и гибкие Custom Chain of Thought процессы за один промпт. На одних Enums можно делать глубокие онтологии, а если еще и использовать tagged unions и списки, то можно отправлять в LLM очень сложные workflows с ветвлениями и повторами.

В OpenAI хорошо видят важность этой технологии. Поэтому неделю назад они сильно повысили лимиты того, как можно использовать Structured Outputs:

- Свойства объектов: 100 → 5000
- Символы в строке: 15 000 → 120 000
- Значения Enum: 500 → 1000
- Всего символов в строках Enum с количеством значений >250: 7500 → 15 000

А что же с причиной +1? Все эти три причины хороши, но самая полезная фишка Structured Outputs в том, что они позволяют делать тестируемые системы!

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

Можно сначала в ответе встроить Structured Output, чтобы система выдавала “начинку” своих размышлений в виде структуры. Скажем, пусть выдаст категорию вопроса (enum), использованный workflow/agent (enum), список ссылок на релевантные документы (list of objects), категорию типа ответа (enum) итп. Такой тип ответа очень легко покрывается простыми evals и тестовыми наборами данных.

А последний шаг работы системы - это будет “разворачивание” сухого структурного ответа в человекочитаемый. Он уже не такой важный (самое сложное позади), и его можно для спокойствия тестировать LLM-as-a-judge.

Вам приходилось использовать Structured Outputs в test evals для оценки качества работы системы?

Ваш, @llm_under_hood 🤗

Иллюстрация к посту про Schema-Guided Reasoning (SGR)

Ваш, @llm_under_hood 🤗

Schema-Guided Reasoning (SGR)

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

Да, это тот самый SO CoT/Custom CoT, про который мы уже год говорим в нашем комьюнити. Только Custom Chain of Thought, несколько путает людей, а ведь паттерн позволяет паковать довольно сложные нелинейные рассуждения в один промпт.

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

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

Используя схемы (Structured Output/Constrained Decoding) вы получаете предсказуемые и контролируемые рассуждения, можете точно оценивать промежуточные результаты (evals), повышать качество и делать ход рассуждений модели - более прозрачным.

В схему можно закладывать не только онтологии (например, enums), но и ветвления (tagged unions in Pydantic), процедуры (nested objects), циклы (lists) и некоторые дополнительные ограничения (см иллюстрацию)

Почему это полезно:

(1) получаем более стабильные результаты при повторных вызовах, даже на разных моделях
(2) каждый шаг рассуждения становится явным и доступным для анализа.
(3) появляется возможность прямой оценки и улучшения промежуточных шагов (типизированные поля не требуют LLM-as-a-judge). А дальше - см quality is a trajectory.
(4) можно преобразовывать экспертный опыт и чеклисты в исполняемые сценарии. Сюда хорошо ложится DDD метолодогия.
(5) нередко получается прирост точности в 5-10% за счет контроля и возможности видеть цепочку рассуждений
(!) Повышается качество слабых моделей - особенно локальных (без SGR с ними работать почти невозможно)

Технология хорошо поддерживается OpenAI, Mistral, Fireworks AI и современными локальными движками для inference (например, vLLM, ollama, TensorRT). Gemini поддерживает частично.

Ваш, @llm_under_hood 🤗

PS: Английская статья про SGR с примерами