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

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

Сталкивались с таким, когда допиливали своего агента, копилота или продукт с 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)

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

Update: набор материалов про 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 🤗

SGR Benchmark моделей - OpenAI OSS модели хороши

Раньше я этот бенчмарк называл LLM Reasoning бенчмарк. Но по факту, тут у всех моделей работает Schema Guided Reasoning (SGR). В каждой задаче есть своя схема рассуждений, которая проводит модель по ключевым точкам и подводит к ответу. Если у модели есть Structured Outputs (SO), то следование схеме размышлений гарантировано, а если нет, то модель может и слететь с "рельсов". Когда такое происходит, ответ вылетает с ошибкой (см колонку Err).

Чем мощнее модель, тем лучше она может справиться с задачей следования схеме без constrained decoding.

На данный момент, именно так и обстоит ситуация с новыми моделями от OpenAI - GPT OSS 120B и 20B. Пока ни один из провайдеров (даже Fireworks) не поддерживает constrained decoding из-за новой архитектуры.

20B заняла 18е место, что стало лучшим результатом для модели такого размера. А вот 120B при использовании SGR попала сразу на 3 место, что просто невероятно 🥳

Говорят, что локальную модель 120B можно запускать со скоростью 1000 tokens/second на H100/B200 и 10-50 tokens/sec на Mac M4. А 5090 вывозит 20B со скоростью 250 tokens/second.

Спасибо OpenAI за классный подарок!

Ваш, @llm_under_hood 🤗

Бенчмарк GPT-5 моделей - первое место, и интересное про OSS модели

Базовая GPT-5 модель от OpenAI сразу попала на первое место. По сравнению с предыдушими моделями, у нее улучшились когнитивные способности и работа со сложным BI кодом. Просто работа с инженерными задачами и так уже 100% на моем бенчмарке. Опять надо усложнять.

gpt-5-mini работает примерно на уровне gpt-oss-120b, причем показатели сильно совпадают. Она заняла четвертое место.

gpt-5-nano заняла 15 место. Она на ~5% пунктов лучше, чем gpt-oss-20b.

Update: запустил gpt-oss-20b в режиме SO и цифры красиво совпали и тут.

У меня есть теория (из-за схожести показателей), что mini и nano - это какие-то свои reasoning режимы работы 120B и 20B. Но проверить это нельзя, т.к. OpenAI API долго думает свой ответ на задачи, а потом возвращает схему с пустыми слотами на размышления (это не reasoning traces, а именно типизированные поля в SGR схеме) Похоже, что не хотят светить свой CoT. У вас так же?

Если теория верна, то можно сделать такой вывод - для GPT-5-120B обычного Schema-Guided Reasoning достаточно, чтобы поднять его на уровень gpt-5-mini, но для модели послабее (20B) потребуется более развитая схема. Жалко, что пока не подсмотреть, как это делают в OpenAI.

Здорово, что вышли новые модели, которые обновили топы. И здорово, что OpenAI открыто поделились такими мощными моделями в Open Source. Осталось только научиться использовать 20B на полную катушку.

Ваш, @llm_under_hood 🤗

PS: Возможно, это подстегнет Anthropic и остальных начать тоже шевелиться, ибо новый GPT-5 очень хорош в кодинге. А у Anthropic до сих пор даже нет constrained decoding по схеме 😂

Локальная gpt-oss-20b - эквивалент закрытой gpt-5-nano, а mini - 120b 🔥

Теперь все цифры сошлись. Я таки запустил gpt-oss-20b, как если бы reasoning у него изначально работал с поддержкой Structured Outputs.

Сейчас gpt-oss-20b из-за новизны архитектуры работает без Structured Outputs даже у Fireworks (это мне подтвердили ребята в OpenRouter). Но, думаю, для таких хороших моделей завезут поддержку новой архитектуры достаточно быстро.

В итоге - очки на моем бенчмарке получились у моделей похожие. Смотрите сами. Причем ситуация аналогична паре моделей gpt-5-mini и gpt-oss-120b.

В принципе, это логично. Зачем OpenAI поддерживать большой зоопарк моделей, когда можно обучить три новые модели, выдать по API все три (спрятав reasoning) и раздать всем две младшие модели? Ну а смогут ли люди получить от локальных моделей результаты аналогичные их облачным вариантам - это уж зависит от самих людей.

Можете проверить сами, скачав локальные модели с Hugging Face (20B и 120B) и запустив у себя, или через одного из провайдеров (списки - 20B и 120B).

Для честного сравнения с gpt-5-nano и gpt-5-mini обязательно давайте локальным моделям возможность подумать над проблемой до ответа, как это делается в CoT. А когда в xgrammar/outlines появится поддержка constrained decoding для 120B/20B, то можно будет и Schema-Guided Reasoning использовать (как это делается в бенчмарке).

Ваш, @llm_under_hood 🤗

Новые материалы по SGR - Schema-Guided Reasoning

Я собрал воедино и структурировал материалы про SGR для LLM, выделил паттерны (их всего три) в отдельные статьи (english). Получилась краткая методичка "собери сам свою reasoning систему":

- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.

Сейчас я работаю над еще одним дополнением - минимальным примером бизнес-ассистента, который может использовать несколько инструментов для распутывания сложных задачек. Он создается без сторонних библиотек, исключительно на OpenAI SDK, Pydantic и всего с одним промптом.

Как думаете, в сколько строчек Python можно уложить такое демо-решение?

Ваш, @llm_under_hood 🤗

Релиз линейки gpt-5 - это самый крутой подарок от OpenAI разработчикам. Включая тех, кто хочет запускать мощные модели на старых картах.

Смотрите.

(1) gpt-oss-120B занимает 5 место в бизнес бенчмарке при использовании SGR. И заодно 4-е место в виде gpt-5-mini (ибо модели идентичны).

(2) это модель с открытыми весами. Бери и используй. Качаем тут.

(3) 120B запускается неплохо (10-30 tokens per second) на старых картах (5-8GB VRAM для attention в bf16) и простой оперативке (советуют 64GB)! Это все благодаря Mixture of experts архитектуре, которая использует только часть весов.

Про запуск 120B - можно почитать на Reddit. Если кратко у llama есть переключатель —cpu-moe, который позволяет использовать всякие 3060Ti или 3090 для запуска модели.

"Yeah, I'm now also hitting > 30T/s on my 3090"

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

Ваш, @llm_under_hood 🤗

PS: в ollama еще не завезли. Следить тут.

У @VaKovaLskii из @neuraldeep есть RAG бот, который может отвечать на вопросы по материалам канала и чата нашего комьюнити.

Бот появился впервые месяцев 8 назад и недавно ожил снова, пополнился новыми постами.

Бот работает как Custom ChatGPT - находит релевантные сообщения и на их основе синтезирует ответ. Ответы не всегда точные, но всегда сопровождаются ссылками на оригинальные сообщения, поэтому все можно перепроверить.

Пообщаться с ботом можно тут: @neuraldeepbot. Прочитать о нем тут.

Ваш, @llm_under_hood 🤗

Я доделываю небольшую демку, которая показывает, как сделать планируюшего бизнес-ассистента с доступом к инструментам, на базе Schema-Guided Reasoning и недорогой модели.

Код я потом выложу в статье.

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

Вопрос. Как вы думаете, сколько строчек кода в этой демке?

Подсказка:
- Система не использует GPT-5. Модель под капотом даже не из TOP-20 моего SGR бенчмарка, ибо для такой простоты ничего мощного не нужно.
- Никаких сторонних фреймворков не используется. Tool Use тоже самописный (tools интегрированы с планировщиком и работают на одном-единственном SGR-промпте). Только openai и pydantic.
- Реализована простая in-memory CRM система с инвойсами, продуктами, памятью, отправкой писем.

Итак, сколько строчек кода может быть в такой демке? Каждая строчка не более 80 символов, и это не code golf, естественно.

Ваш, @llm_under_hood 🤗

PS: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))

Проблемы с GPT-5 моделями у OpenAI

Итак, исходные веса gpt-oss OpenAI моделей - это, на мой взгляд, самое крутое, что давали в свободное пользование со времен Llama. Модели очень хороши и умны.

Но вот с реализацией reasoning у линейки GPT-5 есть вопросы.

Во-первых, при запуске gpt-5/mini/nano (OpenAI API) со Structured Outputs код периодически падает с ошибкой парсинга. Хотя, казалось бы, такое не должно быть возможным - как может constrained decoding по схеме генерировать код, который не соответствует схеме?

При этом тот же код никогда не падает при работе с gpt-4o.

Скорее всего, проблема в том, как constrained decoding интегрировали в новую reasoning схему у gpt-5-mini/nano на новых inference серверах.

Во-вторых, GPT-5 Pro (самая умная) субъективно заметно поглупела. Например, если просто взять весь код с этой ошибкой парсинга и задать вопрос в DeepResearch про первопричины, то эта модель откровенно начинает глупить: "а в чем проблема? А как должен работать constrained decoding? итп". Плюс в процессе работы постоянно упускает из виду моменты, про которые мы уже говорили в рамках контекста.

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

Но в итоге обе сходятся во мнении, что проблема, скорее всего, в сырой реализации constrained decoding на моделях GPT-5.

TLDR;
- gpt-5 в OpenAI API пока плохо работают с Structured Outputs. Ждем фиксов или используем локально gpt-oss со своим constrained decoding
- GPT 5 Pro субъективно стал слабее. Используем пока o3.

Замечали такое?

Постоянные читатели канала помнят, что такое у OpenAI происходит периодически:

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

Поэтому снова ждем третьей стадии

Ваш, @llm_under_hood 🤗

Демка бизнес-ассистента, которая показывает основы построения reasoning системы c tool use на базе простой LLM (GPT-4o)

Ассистент умеет:
- генерировать инвойсы и отменять их
- отправлять письма с вложениями
- создавать правила самому себе на будущее
- читать данные клиентов

(на самом деле интеграций с реальными системами нет, агент работает в симуляции)

Из библиотек требуется только openai/pydantic для Structured Outputs и rich (для красивого вывода в терминал). Все остальные вещи вроде демо-БД и инструментов реализованы прямо в коде.

Всего в демке 159 строчек исполняемого кода. Большая часть которого - SGR схема инструментов (у ассистента всего один промпт) и реализация работы самих инструментов.

Статья с демкой - SGR Demo. Код одним файлом - в статье после разбора.

Для тех, кому хочется более серьезного кода, в статье есть раздел "Hardening the code" про то, как можно эту обучающую демку развить дальше.

Ваш, @llm_under_hood 🤗

---
Полный список статей:

- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
- SGR Demo - минимальное демо бизнес-ассистента с SGR под капотом.

Демо reasoning бизнес-ассистента с SGR на JS

Спасибо Антону (@antonkuzminru) за этот порт!

Его код работает аналогично версии на Python и тоже использует минимум фреймворков. Вместо pydantic в мире JS/TS используется zod.

- TS (Bun) + Zod - Gist 👈

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

Ваш, @llm_under_hood 🤗

Красивое демо бизнес-ассистента с SGR на Python

Спасибо Виталию (@vitalii_ask) за версию агента с красиво оформленной визуализацией!

Код работает аналогично версии на Python, но с более симпатичным оформлением и отображением результатов работы инструментов. Заодно сохраняет результат работы в markdown отчет. Фреймворки те же.

Ссылка на Gist

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

Ваш, @llm_under_hood 🤗

Меня сегодня спросили - есть ли идеи по поводу следующего Enterprise RAG Challenge?

Я сказал, что есть две:

(1) Сделать ERC, как он был в прошлые два раза (поиск ответов на вопросы в отчетах), но заранее подготовить базовый стенд, в котором реализованы простые pipelines. Команды смогут взять этот код и работать над его улучшением. Веселье с парсингом документов и таблиц гарантировано.

(2) Сделать Enterprise Reasoning Challenge, где команды получают легковесную среду, которая симулирует небольшую компанию с внутренними системами (ERP/Emails/CMS итп). Это похоже на симулированный пример из демки бизнес-ассистента, но с бОльшим количеством доступных сервисов.

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

Вам какая идея больше нравится для дружеского соревнования этой осенью? И почему?

Ваш, @llm_under_hood 🤗