Граница код | модель как архитектурный объект
Граница код | модель как архитектурный объект Накидаю мыслей поверх одного проекта: архитектура — router + pipelines (AWS, Claude). Возьмём кейс, который видел почти каждый, кто пилил LLM-агента для вопросов к данным на человеческом языке: text2sql, аналитический ассистент, бот поверх базы — неважно. Схема обычно такая: агент тащит всё на себе. Сам решает, что за запрос пришёл, сам его собирает, сам выбирает, в каком виде отдать ответ, и сам же прикидывает, стоит ли предупреждать про отклонение. В этом и весь смысл агента, ради этого и пишется системный промпт. На десятке тестовых вопросов всё летает. А потом прилетает боль: вопросы приходят в других формулировках. Тот же самый вопрос, но сказанный иначе, обрабатывается по-другому — модель иначе прочитала фразу, и структурно одинаковые результаты вдруг поехали в разной форме (строка, таблица, график), причём без объяснения почему. Или наоборот: формулировка та же, а отклонение то с пояснением, то пустое. Что делают первым делом? Дописывают в промпт ещё одно правило. Пару раз реально выручает. А потом новое правило начинает грызться со старыми, и промпт превращается в лоскутное одеяло из заплаток под конкретные случаи. Нестабильность никуда не девается — она просто зарывается в том, в каком порядке модель применяет взаимоисключающие инструкции. Корень в другом: в этом сценарии вообще никто явно не решал, что делает код, а что модель. Оно сложилось само, пока промпт сочинялся. Отсюда и решение: граница между кодом и моделью — не деталь реализации, а отдельный архитектурный объект. Не примешь это решение осознанно — его примут за тебя по дефолту, и почти наверняка не в сторону устойчивости. Читать далее 👉 Telegram | Max