Как проектировать ИИ-продукты: разбор типовых ошибок и паттернов

Как выбрать инструмент: код, ML или LLM

Первый вопрос, с которым сталкивается команда перед разработкой ИИ-продукта, — не «какую модель взять», а «нужна ли вообще модель». Все задачи можно разделить на четыре класса, и для каждого — свой инструмент:

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

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

Почему у агента «проваливается» середина контекста

Типовая ошибка в работе с LLM и агентами — перегрузка контекста. Чтобы её избежать, стоит разобраться, как устроено внимание модели во время инференса.

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

Чем можно случайно забить контекст агента:

• большим системным промптом;
• большим наборои инструментов — каждый инструмент, в том числе подключённый через MCP, занимает место в контексте;
• ответами инструментов, запросами к ним, токенами рассуждений;
• долговременной памятью, которая может «подняться» в контекст, если агент решит, что ему нужна какая-то информация из неё.

Пирамида памяти агента

Можно представить память агента в виде пирамиды из трёх уровней:

• Наверху — краткосрочная память: то, что уже находится в контексте прямо сейчас.
• Чуть ниже — информация, которая не в контексте, но легко подгружается: скиллы, данные о проекте и пользователе — они могут храниться в файле (для локального агента) или дополнительными инструкциями (для облачного).
• В основании — долговременная память: вся память, доступная агенту (не вся информация в мире, а именно то, что агент может подгрузить).

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

Как сократить контекст: промпт, инструменты и диалоги

Первая и самая простая техника — оптимизация промпта по принципу Keep it simple (Short and simple). Контекст должен быть достаточным для выполнения задачи, но не перегруженным: не стоит добавлять в промпт все возможные сценарии, всю базу знаний и все документы сразу. Промпт должен содержать минимально необходимую информацию о проекте — над чем идёт работа, в какой компании, в каком отделе, какая роль у агента.

Что ещё ограничивает контекст:

• Набор инструментов. Рекомендуем не более 10, максимум 15 инструментов на агента — с бо́льшим числом модель начинает путаться. Если инструментов нужно больше, есть смысл вынести их в отдельного субагента.
• Новая задача — новый диалог. Не стоит пытаться до упора забивать контекст в одном диалоге, ссылаясь на то, что у модели «миллион токенов поддержки контекста» — на практике эффективно используется в основном начало и конец окна.
• Специализация промпта. Общий промпт даёт общий ответ, специализированный промпт — детерминированный. Если нужен не размытый, а конкретный ответ, в промпт стоит заранее заложить максимум специфики задачи. Например, что используется облачный Kubernetes^® и проект с определённым наименованием — чтобы агент не делал дополнительных уточняющих запросов, которые сами по себе забивают контекст.

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

Как оценивать качество ответов агента

Eval и подход LLM as a Judge позволяют повышать качество вывода без дополнительных инструментов — промпт дорабатывается так, чтобы модель выдавала оценку либо в режиме рассуждения, либо за один проход.

Перед оценкой важно сформулировать цель и метрики: релевантность, точность, полноту, а также бинарные критерии, если они уместны. Ключевое отличие LLM as a Judge от классических алгоритмов оценки — модель может объяснить, почему поставила именно такую оценку.

Данные для оценки берут из двух источников: реальных взаимодействий с пользователями (прогнать через промпт и посмотреть, насколько ответ агента совпадает с ожиданиями) или синтетики, сгенерированной на основе накопленных данных либо мощной LLM.

Как экономить контекст при работе с инструментами

Разные инструменты по-разному влияют на контекст. Разберём основные:

• Векторный поиск. Сюда заносят текстовую информацию и инструкции — то, по чему выполняется семантический поиск, а не данные с идентификаторами пользователя (для них — tool calling). Несколько найденных вариантов ответа попадают в контекст, дальше модель их анализирует.
• Tool calling. Используется, когда нужно точечно получить конкретную статью, текст или описание товара по идентификатору — без выгрузки всего набора данных, как это было бы при векторном поиске.
• Web Search. Для полноценного исследования объём загружаемых данных из веба можно не ограничивать. Но если нужно сократить контекст, у Web Search есть встроенные ограничения — по домену, региону, количеству возвращаемых ответов.
• Tool Interpreter (sandbox). Когда в агента загружается большой документ целиком, модель, скорее всего, потеряет часть информации при его разборе. Вместо этого агент пишет скрипт, который в изолированном окружении (sandbox) сам парсит и анализирует файл, не забивая контекст самим документом, а добавляя туда только то, что нужно после анализа.

Почему не стоит использовать одну модель для всех задач

Ещё один антипаттерн, который можно выделить, — использование одной мощной модели на все случаи жизни.

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

У подхода «одна модель на всё» есть несколько проблем:

• Недетерминированность. Сильные модели каждый раз могут выбирать новый способ решения одной и той же задачи. Агентские скиллы отчасти снимают эту проблему, но не полностью.
• Ограничения по безопасности. При использовании зарубежных моделей могут действовать как внешние, так и внутренние ограничения — например, запрет передавать чувствительные данные, даже если они не персональные. В таких случаях нужно работать на моделях, развёрнутых во внутреннем контуре.
• Стоимость. Мощные модели дорогие и не дешевеют, а LLM-агенты сейчас проникают не только в IT-отдел, как раньше, а во все подразделения компании — рост числа разнородных запросов повышает общую стоимость владения.

Как маршрутизация снижает стоимость ИИ-продукта

Решение — маршрутизация на инфраструктурном уровне, паттерн Agent (LLM) Router. LLM-классификатор — это может быть как LLM, так и модель на основе классической регрессии — определяет тематику запроса и направляет его нужному субагенту с ограниченным набором инструментов и собственным системным промптом. Субагент — специализированный агент, LLM с RAG или большой агент-исследователь — ходит во внутреннюю базу знаний, исследует рынок и конкурентов, может работать с чувствительной информацией, если настроить ограниченный доступ.

Такая конструкция закрывает сразу несколько задач:

• Скономию — дорогая модель подключается только там, где она действительно нужна.
• A/B-тестирование — можно направить часть трафика на новую версию модели или агента и посмотреть на результат.
• Fallback — если сильная модель недоступна, запрос уходит к более слабой.

Когда нужен паттерн-оркестратор и какие они бывают

Если модель или агент не справляется даже после всех оптимизаций — корректировки промптов, режима рассуждения, смены модели, агентских циклов, — можно использовать паттерн-оркестратор (или их серию).

Оркестратор принимает задачу и передаёт её специализированным субагентам — дообученным, со своими инструментами или построенным на базе других LLM.

Можно выделить несколько паттернов оркестрации:

Какой уровень автономности выбрать для агента

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

• Human in the loop (HITL) — человек явно участвует в процессе и периодически призывается внутри агентского цикла.
• Human on the loop (HOTL) — человек присматривает за работой агента со стороны.
• Human out of the loop (HOOTL) — агент работает полностью автономно, человек не подключается.
• AI in the loop — агент консультирует человека, а физическую работу выполняет сам человек. Например, требуется собрать базу техобслуживания для сотни единиц разного оборудования. Держать в голове или в документах такой объём не может ни один человек. Агент подсказывает, какой инструмент взять, какие расходные материалы нужны для конкретных регламентных работ, а расходники заранее размещаются на складе.

Как обеспечить безопасность агентов на прикладном уровне

Сосредоточимся на прикладном уровне — том, что происходит уже внутри агента:

Изоляция контекста

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

В векторном поиске для той же цели используют метаданные — теги файлов (например, «финансовая информация», «IT-информация», «административная информация» и т. д.), которые задают, какой набор данных доступен конкретному агенту.

Минимально необходимые инструменты

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

Отказ от административной учётной записи

В инструмент можно и нужно пробрасывать идентификатор сессии конкретного пользователя, либо использовать паттерн on-behalf-token — токен выдаётся агенту от имени пользователя, и по нему агент обращается к конечным системам, ограниченным тем, что доступно именно этому пользователю.

Отдельный агент для чувствительных данных

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

Guardrails и модерация

Проверка идёт и на входе, и на выходе:

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

В отдельных случаях к проверке подозрительных действий подключают человека — как реакцию на срабатывание guardrails.

Зачем агентам observability

LLM observability — сравнительно новая тема, которая закрывает несколько вопросов:

• Токены и юнит-экономика. Каждый запрос в LLM отправляется в виде трейсов на коллектор с маркировкой по количеству использованных токенов.
• Измерение качества. Накопленные данные (что вошло в агента и что из него вышло) используются для оценки качества выдачи с помощью техник Eval и LLM as a Judge.
• Agentic observability. Возможность проследить каждый шаг агента: какие инструменты вызывались, по какой причине, почему модель решила пойти именно в этот источник данных. Это помогает понять, нужно ли скорректировать системный промпт под нужные инструменты, — или отказаться от каких-то инструментов вовсе.

Для этих задач можно использовать встроенные в Yandex AI Studio инструменты. Данные вызовов агентов по умолчанию попадают в коллектор и доступны в интерфейсе без дополнительной настройки.

Частые вопросы

Что в итоге

• Прежде чем брать LLM, стоит проверить, не решается ли задача классическим кодом или ML-алгоритмом — модель нужна там, где сценарий недетерминирован или задача связана с анализом текста.
• Маршрутизация запросов между моделями и субагентами снижает стоимость и позволяет тестировать изменения на части трафика.
• Контекст — ограниченный ресурс с «провалом» внимания в середине: промпт, набор инструментов и память стоит держать по принципу «минимально достаточно», а не «на всякий случай».
• Когда одного агента недостаточно, помогают паттерны оркестрации — от последовательной цепочки до динамической оркестрации с планированием подзадач.
• Безопасность агентов строится на минимальных привилегиях, изоляции контекста, отказе от административных учёток и guardrails на входе и выходе.
• Observability — токены, качество ответов и трассировка шагов агента — стоит закладывать с самого начала, а не добавлять постфактум.