Как спроектировать предсказуемую LLM-систему: 5 принципов и пример ассистента по ТЗ

Создание LLM-системы, которая в production работает стабильно и предсказуемо, — задача нетривиальная. Многие разработчики сталкиваются с ситуацией, когда демо-версия выглядит впечатляюще, но в реальной эксплуатации модель начинает отвечать невпопад, тратить тысячи токенов на пустые рассуждения или выдавать галлюцинации. Как же спроектировать ассистента, который каждый день выполняет ровно то, что нужно, и не сжигает бюджет? Владимир Суворов, Senior Data Scientist и core-разработчик open-source AutoML-фреймворка OutBoxML, предлагает подход, основанный на пяти инженерных принципах. Разберем их на реальном примере — ассистенте, который сверяет входящий документ технического задания со сводом документации и ставит комментарии о наличии требуемых пунктов.

Пять принципов проектирования предсказуемой LLM-системы

Суворов выделяет пять ключевых принципов, которые позволяют сделать LLM-систему надежной и контролируемой. Первый — жесткое разделение обязанностей. Модель не должна решать, что делать; она только исполняет четко описанные шаги. Второй принцип — детерминированный пайплайн: каждый вызов модели имеет строго определенный вход и выход. Третий — минимальный контекст: модель получает ровно ту информацию, которая нужна для текущего шага, без лишних данных. Четвертый — валидация на каждом этапе: результат каждого шага проверяется программно, и при ошибке система либо повторяет запрос, либо переходит к fallback-сценарию. Пятый принцип — человеко-ориентированный дизайн: пользователь всегда видит, что происходит, и может вмешаться.

Эти принципы автор перенес из расчетной механики, где предсказуемость и контролируемость критичны. В отличие от модных «агентов», которые пытаются имитировать самостоятельное мышление, такой подход превращает LLM в ассистента — инструмент с четкими границами.

Как это работает: пример ассистента по ТЗ

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

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

Почему нельзя давать модели всю задачу сразу?

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

Технические детали: архитектура и валидация

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

Суворов подчеркивает, что такой подход требует больше инженерной работы на этапе проектирования, но окупается стабильностью. В тестах система показала точность 97% на этапе классификации и 94% на этапе проверки полноты, при этом среднее потребление токенов на один документ составило около 1200 — в три раза меньше, чем у монолитного агента, который пытается сделать всё за один запрос.

Кого затронет и как

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

Что будет дальше

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

Итог

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