Архитектор ИИ-систем собрал «Канон» для аналитиков: 17 бизнес-требований за 8 дней

Большинство историй про ИИ-агентов в работе заканчиваются на личной продуктивности: один энтузиаст настроил промпты, и у него всё летает. Николай Карпов, архитектор ИИ-систем, рассказал на Habr, что бывает дальше, когда надо дать такой же результат целому департаменту аналитиков и не заставлять каждого проходить курс промпт-инжиниринга.

Боевая проверка вместо презентации

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

Ключевой вывод: основное время ушло не на генерацию, а на условия доверия. По какому шаблону собирать документ, откуда брать данные, как искать коллизии, что делать при нехватке данных. Когда агент начал выдумывать, помогло не только снижение температуры до 0,2 и top-p до 0,85, но и правила работы с недостающими данными. Параметры, кстати, у других специалистов отличались: им хватало температуры 0,6. Итог: 14 документов за 8 рабочих дней, позже комплект вырос до 17, каждый вычитан человеком и опубликован в Confluence.

Как устроен канон

Автор разделил четыре сущности. Роль отвечает за границы полномочий и работу с неопределённостью. Навык описывает методику: Use Case, интерфейс и API требуют разных проверок. Инструмент это скрипт для повторяемой операции, например сборки DOCX или проверки XML. Шаблон задаёт форму. Подробные инструкции подгружаются только когда нужны, поэтому контекст не забивается.

Структуру проектов тоже пришлось переделать после обратной связи коллег. Сначала было три слоя: исходники, черновики, артефакты. Потом выяснилось, что документ проходит много итераций, и появились каталоги по типам документов, а рядом лежат md/ и docx/. Контракт простой: всё в рабочих каталогах является черновиком, даже если сборка прошла успешно. Принятые специалистом версии уходят в отдельный каталог релиза.

Мелочи, которые решают

Оцифровка исходников названа фундаментом: если агент неверно прочитал таблицу, ошибка утечёт в требования. Сложные таблицы регуляторов с вложенными строками при плоском представлении теряли иерархию, поэтому правило стало жёстким: таблицы только в HTML. Схемы переводят в PlantUML, draw.io или BPMN, но сверяют с оригиналом, ведь синтаксически верная схема не гарантирует верных связей.

Пробелы в данных агент регистрирует в open-questions.md с идентификатором и статусом, а в документе оставляет явную пометку со ссылкой. Выдумывать ответ запрещено, а при следующей сессии он читает реестр и продолжает.

Что из этого забрать себе

Если внедряете агентов в команду, начните не с выбора модели, а с контрактов: кто за что отвечает, где лежат черновики и где принятое, как фиксируются неизвестные. Ошибки пользователей стоит превращать в правки канона, а не оставлять в чате. И не путайте срочную схему с постоянной: переключение между моделями из-за лимитов подписки автор прямо называет решением под давлением, а не рекомендацией. Статья обрывается на середине, поэтому про поддержку через мессенджеры и память остаётся судить по оглавлению, но основа уже полезна тем, кто строит такую обвязку.