Как создать ИИ-агента: из каких частей он собирается и в каком порядке его делают

Пять частей, из которых собирается агент

Любой агент, от простого до сложного, состоит из одних и тех же деталей. Разница только в том, насколько тщательно проработана каждая.

Модель. Языковая модель, которая понимает задачу и формулирует шаги. Её выбирают под объём, скорость и стоимость обращений, а не по громкости названия.

Инструкция. Описание роли, цели, порядка действий и формата результата. Это не одна фраза, а документ: что делать, чего не делать, как поступать в спорных случаях.

Инструменты. То, чем агент действует: поиск по документам, чтение таблицы, запись в систему учёта, отправка черновика на проверку. Без инструментов это просто собеседник.

Данные. Сведения о компании, на которые агент опирается: условия, цены, регламенты, типовые ответы. Их качество определяет, будет он точен или начнёт сочинять.

Ограничения. Что агенту запрещено: отправлять без проверки, обещать сроки, менять цены, выходить за пределы задачи. Этот слой часто забывают, а именно он отвечает за безопасность.

Конструктор или программная разработка

Путей сборки два, и выбор между ними определяет сроки и потолок возможностей.

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

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

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

Практическое правило: прототип делают в конструкторе, чтобы за неделю проверить саму идею на реальных примерах. Если идея подтвердилась и упирается в ограничения конструктора — переносят в код. Сразу писать код под непроверенную идею обычно дороже.

<form action="/api/lead" method="post">
  <label>Телефон или почта
    <input name="contact" autocomplete="email" required>
  </label>
  <input type="hidden" name="page" value="/service/">
  <button type="submit">Отправить</button>
</form>

Этапы работы от идеи до запуска

Последовательность, которая встречается почти в любом проекте.

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

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

3. Набор эталонных примеров. Реальные случаи из прошлого с правильными ответами — не меньше пятидесяти, лучше сотня. Включая неудобные: неполные, двусмысленные, нестандартные.

4. Прототип. Минимальная версия, которая проходит путь от входа до результата.

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

6. Доводка. Правка инструкции, данных и ограничений по итогам разбора. Этапы 5 и 6 повторяются несколько раз.

7. Пилот на части потока. Работа на реальных обращениях с обязательной проверкой человеком.

Как проверять качество до запуска

Самая частая ошибка — оценивать агента по демонстрации. Три удачных примера показывают, что агент умеет работать, но не показывают, как часто он ошибается.

В продолжение темы можно открыть Журнал ошибок ИИ: как превращать сбои в улучшения: там следующий шаг разобран отдельно.

Рабочий способ — эталонный набор. Берёте сто реальных случаев из прошлого, для каждого записываете правильный результат и прогоняете через агента. Дальше считаете три цифры.

Доля полностью верных ответов. Результат можно использовать без правок.

Доля ответов с правкой. Суть верна, но нужна доводка человеком.

Доля опасных ошибок. Выдуманный факт, неверная цифра, действие не по инструкции. Это главный показатель: даже небольшая доля таких ошибок может сделать агента непригодным для работы без проверки.

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

Где проекты застревают

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

На данных. Выясняется, что условия разбросаны по десяти документам и противоречат друг другу. Агент их не примиряет, а выбирает случайную версию.

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

На пограничных случаях. Девяносто процентов обращений агент обрабатывает хорошо, а на оставшихся десяти ведёт себя непредсказуемо. Именно эти десять процентов съедают больше всего времени на доводку.

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

Из чего складывается бюджет разработки

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

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

Разработка прототипа — на удивление недорогая часть, особенно в конструкторе.

Доводка по итогам проверок — несколько циклов правки и повторного прогона. Её часто не закладывают, и проект упирается в неё после первого показа.

Подключение к системам — непредсказуемая часть: зависит от того, насколько открыты ваши системы.

Обращения к модели — постоянный расход, зависящий от объёма. Считать его стоит на рабочем потоке, а не на тестовом.

Сопровождение — ежемесячная статья после запуска.

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

Сделать самим или заказать

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

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

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

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