Размышление по мотивам проекта. Архитектура – router + pipelines (AWS, Claude).
Рассмотрим сравнительно простой пример, знакомый почти всем, кто делал LLM-агента для запросов к данным на естественном языке – будь то text2sql, аналитический ассистент или чат-бот над базой. Обычно агенту поручают решать всё самому – и определять тип запроса, и формировать его, и выбирать форму результата и решать, нужно ли предупредить об отклонении. Именно в этом суть агента и именно для этого пишется системный промпт.
На десятке тестовых вопросов система работает без нареканий. Но позже появляются проблемы, когда вопросы начинают приходить в разных формулировках. Например, один и тот же вопрос, заданный другими словами, вдруг обрабатывается иначе – модель по-другому интерпретировала фразу и одинаковые по структуре результаты приняли разную форму (строка, таблица, график) без объяснения причины. Или при одной той же формулировке вопроса отклонение то получает пояснение, то приходит пустым.
Первое, что обычно меняют в таких случаях – добавляют в промпт ещё одно правило. Несколько раз это действительно помогает. Потом новое правило начинает противоречить старым, и промпт превращается в набор заплаток под конкретные ситуации. Нестабильность никуда не уходит, она просто прячется теперь в том, в каком порядке моделью применяются противоречащие друг другу инструкции.
Именно здесь кроется и проблема, и ее решение. Проблема в том, что в описанном сценарии работы никто явно не решал, что в системе делает код, а что модель. Это сложилось само, по ходу генерации промпта. Спросите, почему модель выбирает форму результата запроса, а не разработчик пишет десять строк обычного кода, – и внятного ответа, как правило, не найдётся. Отсюда и решение: граница между тем, что делает код, и тем, что делает модель, – это не деталь реализации, а отдельный архитектурный объект. Если такое решение не принять явно, оно всё равно будет принято по умолчанию, и чаще всего не в пользу устойчивости системы.
