Граница между кодом и моделью: как спроектировать надежного LLM-агента

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

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

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

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

Основная идея: Проведение жесткой границы между алгоритмом и нейросетью

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

Концептуально это разделение было описано компанией Anthropic в руководстве по построению эффективных агентов (Building Effective Agents). В классических рабочих процессах (workflows) управление потоком данных полностью передано заранее написанному коду. В полноценных агентах вектор движения определяет сама нейросеть.

Известным частным случаем проведения этой границы является паттерн каскадной маршрутизации (cascade routing). В этой схеме первичную обработку выполняет дешевая эвристика или легковесная модель, а при недостаточном уровне уверенности происходит эскалация запроса к более сложной и дорогой LLM. Однако ключевой вопрос заключается не в самой маршрутизации, а в том, где именно эта граница начинает «плавать» и какими программными методами ее необходимо фиксировать.

Первое правило: Принцип асимметрии при повышении и понижении сложности

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

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

Ошибка завышения категории и ошибка ее занижения кардинально отличаются по своей природе:

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

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

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

Второе правило: Борьба с необнаружимыми ошибками через прозрачность кода

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

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

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

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

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

Третье правило: Отказ в обслуживании как жесткая логика программного кода

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

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

1. Дефект формы: Пустой, поврежденный или нечитаемый ввод. Это чисто техническая проблема, которую программный код должен отсекать еще до обращения к LLM.
2. Дефект права и политики: Изначально неправомерный или находящийся вне рамок системы вопрос. Попытки задать такой вопрос должны блокироваться детерминированными правилами на уровне API или входного фаервола.
3. Дефект отсутствия данных: Запрос сформулирован корректно, но в целевой базе данных отсутствуют необходимые сущности. Это выясняется только на этапе сопоставления структуры запроса с предметной областью.

Если свести все три сценария к единой команде в промпте «отказывай при некорректности», нейросеть неизбежно смешает принципиально разные логические основания. Более того, отказ, который пользователь может обойти простым перефразированием вопроса, не является отказом по существу — это лишь проявление нестабильности модели.

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

Вывод: Архитектурный чек-лист для разработчика

Все рассмотренные сценарии сводятся к единому фундаментальному вопросу: кто именно и на каком основании принимает решение в каждой конкретной точке потока данных.

Практический принцип проектирования предельно прост:

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

Постскриптум: Практическое удержание границ

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

Взгляд на рынок: От найма к разработке собственных продуктов

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

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

Источник: habr.com