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