LLM-First или Code-First? Где интеллект размещается в производственном ИИ

Как решить, что должна обрабатывать модель, что — ваш код, и как связать их между собой.

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

Это изменение разделило область на две части — LLM‑First и Code‑First

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

В архитектуре Code‑First программное обеспечение/код остаётся ответственным за последовательность, бизнес‑правила, валидацию, разрешения и выполнение. LLM здесь выступает как специалист, к которому код обращается, когда требуется понимание или генерация языка.

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

Почему LLM‑First так привлекателен

Традиционное программное обеспечение работает прекрасно, когда требования можно точно сформулировать. Например, пользователь выбирает продукт, вводит сумму и отправляет платёж. Вы определяете допустимые состояния, правила валидации, условия ошибок и последовательность транзакций в коде. Всё готово.

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

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

Здесь LLM играет важную роль, выступая гибким слоем рассуждения между человеческим языком и вашими детерминированными сервисами. Именно поэтому агенты привлекают столь большое внимание. руководство Google Cloud по агентной архитектуре ИИ описывает агента как приложение, в котором ИИ‑модель служит движком рассуждения, а инструменты позволяют ей обращаться к внешним системам и данным.

Anthropic’s Building Effective AI Agents руководстводелает различие, к которому я постоянно возвращаюсь. В рабочий процесс, модели и инструменты следуют по путям, определённым вашим кодом. В агент, LLM управляет собственным процессом и решает, как использовать инструменты. То же руководство рекомендует начинать с самой простой архитектуры, решающей задачу, вместо того чтобы добавлять агентную сложность рефлексивно. Я бы подчеркнул этот совет дважды.

Ограничения подхода «Позволь модели решать»

Модель может рассуждать о том, что должно произойти. Рассуждение не равно принудительному исполнению правила.

Например, возьмём финансовый рабочий процесс. LLM может отлично понимать запрос “перевести ту же сумму, что я отправлял в прошлом месяце тому же поставщику”. Но должна ли она также решать, авторизован ли перевод, рассчитывать нормативные лимиты, проверять право собственности на счёт, переопределять политику безопасности и выполнять транзакцию?

Скорее всего, нет. Эти задачи детерминированы, тестируемы, проверяемы и исполняемы, и именно в этом традиционное программное обеспечение превосходно. Риск растёт, когда модели получают доступ к инструментам. руководство OWASP по безопасности генеративного ИИ отмечает чрезмерную автономию как значительный риск: предоставление системе на основе LLM более широких возможностей, разрешений или автономии, чем требуется задаче. Странный или подделанный вывод модели — это одно, когда она генерирует текст. Это гораздо более серьёзно, когда модель может действовать в реальном мире.

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

Code‑First всё ещё важен

С учётом стремительного развития ИИ легко почувствовать, что традиционная инженерия вышла из моды. Я бы сказал обратное. ИИ делает надёжные детерминированные системы более важными, а не менее.

Код по‑прежнему является правильным выбором, когда задача требует точного воспроизводства. Аутентификация — простой пример. Модель не должна “рассуждать”, имеет ли кто‑то административные привилегии. Ваше приложение должно обращаться к авторитетной системе управления идентификацией и доступом. То же относится к денежным расчётам, проверкам прав доступа, валидации данных, нормативным ограничениям, лимитам транзакций, проверке схем и всему, что необратимо. Для этого нужны явные контракты, а не предположения.

Это соответствует более широкому мышлению в сфере управления. NIST AI Risk Management Framework требует от организаций управлять рисками ИИ на этапах проектирования, разработки, внедрения и использования. Его сопутствующий Generative AI Profile добавляет, что генеративные системы могут потребовать дополнительного надзора, документирования, проверки и контроля, в зависимости от уровня риска.

Поэтому я считаю полезным разбивать каждое проектное решение на два вопроса:

Что должно произойти?

и

Что допускается происходить?

LLM часто может помочь с первым. Детерминированные системы обычно должны отвечать за второе.

Гибридный шаблон: рассуждать вероятностно, выполнять детерминированно

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

Пример. Представьте, что AI‑ассистент помогает разработчикам создавать временные среды для тестирования API, и разработчик вводит: «Создай мне песочницу для рабочего процесса онбординга клиента».

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

Примерное разделение выглядит так:

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

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

Границы становятся важнее по мере роста возможностей агентов

Это разделение становится более важным по мере перехода от ассистентов к агентам. Ошибочный ответ ассистента доставляет неудобства пользователю. Агент с правом записи в продакшн может вызвать гораздо более серьёзный беспорядок.

Исправление заключается не в том, чтобы полностью убрать автономию. Речь идет о постепенном добавлении автономии при сохранении явных точек контроля. Руководство Google по многопользовательским системам рекомендует сочетать динамичное поведение ИИ с детерминированными средствами безопасности, наблюдаемостью, чётко определённой автономией и человеческим контролем для бизнес‑критических сценариев.

Одобрение человеком также может быть встроено непосредственно в рабочий процесс, а не выступать в роли неформального резервного механизма. Microsoft’s agent framework documentation например, поддерживает вызовы инструментов, которые приостанавливаются до тех пор, пока человек явно не одобрит запрашиваемую операцию.

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

Пять вопросов, которые следует задать перед передачей задачи LLM

Когда я решаю, должен ли компонент быть LLM‑first или code‑first, я прохожу через следующие вопросы:

1. Есть ли у задачи один объективно правильный ответ? Если да, склоняйтесь к детерминированному коду. Расчёты налогов, разрешения и проверка схемы не должны изменяться из‑за того, что модель интерпретирует их иначе сегодня.
2. Включает ли она неоднозначный язык или неструктурированную информацию? Если да, LLM может принести реальную ценность.
3. Что произойдёт, если модель ошибётся? Правильная архитектура для резюме встречи сильно отличается от архитектуры для инициации платежа.
4. Можно ли независимо проверить вывод? Планы, сгенерированные LLM, становятся гораздо безопаснее, когда детерминированные правила могут проверять полученное действие до его выполнения.
5. Нужен ли действительно агент? Если шаги уже известны, обычный рабочий процесс с несколькими целевыми вызовами LLM обычно проще, дешевле, легче тестировать и эксплуатировать.

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

Надёжность — это архитектурное свойство, а не подсказка

Многие команды начинают пытаться повысить надёжность почти исключительно с помощью инженерии подсказок. Подсказки важны, но они не могут нести всю нагрузку.

Производственная система должна предполагать, что вывод модели иногда будет неполным, искажённым, неожиданным или просто ошибочным. OWASP Top 10 для LLM‑приложений перечисляет такие риски, как prompt injection и improper output handling, что подкрепляет важный принцип: рассматривать вывод модели как недоверенный ввод для последующих систем, а не как инструкции для автоматического выполнения.

Это меняет задаваемый вопрос. Вместо «Как написать запрос, который всегда заставит модель соблюдать правило?», спросите «Как спроектировать систему так, чтобы правило нельзя было нарушить, даже если модель ошибётся?»

Это проблема архитектуры программного обеспечения, а не подсказок. Запрос может сказать агенту не выполнять неавторизованное действие. Сервис авторизации действительно может его остановить. Эти два контроля не эквивалентны.

За пределами спора: системы с приоритетом намерения

Размышляя об этом, я пришёл к выводу, что дебаты LLM‑first против code‑first указывают на третью идею: intent‑first архитектуру.

В системе с приоритетом намерения приложение начинается с понимания того, чего пользователь пытается достичь. Именно здесь LLM наиболее ценен, потому что люди редко формулируют свои желания точно. Затем система постепенно преобразует эту неопределённость в структурированные, детерминированные операции.

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

Некоторые из этих этапов выигрывают от рассуждений языковой модели. Другие должны быть реализованы как фиксированные сервисы. Архитектура определяется не тем, кто «выигрывает» — ИИ или код, а тем, где допустима неопределённость.

Итог

По мере улучшения моделей будет соблазн предоставлять им контроль над всё более крупными частями стека. Иногда это будет правильным решением. В других системах наиболее продуманный дизайн будет тем, который сознательно предоставляет модели меньше полномочий.

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

Будущее корпоративного ИИ, вероятно, не будет полностью LLM‑first или полностью code‑first. Это LLM там, где неопределённость требует интеллекта, и код там, где определённость требует контроля.

Это различие может иметь гораздо большее значение, чем выбранная вами модель.