На связи Сергей Смирнов, AI-инженер LLMStart.ru. Сегодня расскажу о полноценном кейсе, который мы делали для компании Айтон: агенте-консультанте по 1С:УНФ, который помогает отвечать на вопросы клиентов по базе знаний, реальным диалогам поддержки и контексту конкретного обращения. Разберу всю хронологию, нюансы и путь от первой гипотезы до продакшена, которым уже пользуются клиенты.
Для бизнеса этот кейс интересен как пример реальной автоматизации через ИИ: сначала ассистент для сотрудников, потом сервис для клиентов. Для технарей — подходом, где решение эволюционировало от RAG-прототипа к агенту на основании данных и метрик, а не потому, что «так модно».
Сразу оговорюcь, чего в этой статье не будет. Это не туториал по LangChain и не обзор того, как вообще устроены AI-агенты — таких материалов хватает. Это разбор одного производственного кейса под одним углом: как на каждом шаге именно измерения определяли, какой должна быть архитектура. Где данные говорили «достаточно простого RAG» — мы оставались на простом RAG; где показывали, что прямой цепочки уже мало, — двигались к агенту. Архитектура здесь не предшествует измерениям, а следует за ними.
Заложник очереди
Айтон более двадцати лет внедряет, сопровождает и дорабатывает 1С:УНФ — «Управление нашей фирмой».
За эти годы у компании накопилась огромная база знаний и большой штат консультантов; и вместе с ними — операционная нагрузка, которую дальше я разберу в цифрах. Продукт, о котором речь, — бот-консультант на базе большой языковой модели по 1С:УНФ. Пользователи на первом этапе — сами консультанты Айтона, которым нужно быстро найти ответ для клиента и попутно разобраться в теме. На втором — клиенты компании напрямую. Класс вопросов — из реальной практики: «как провести возврат, если не попадает доставка», «на что влияет вот этот флаг» (со скриншотом формы), «есть ли в УНФ такая функция и как её включить». Часть таких вопросов — терминологически неоднозначна, и без уточнения отвечать нельзя.
В среднем в службу поддержки Айтона вопрос приходит примерно раз в 5 секунд — это около 6 тыс. вопросов в день и порядка 100 тыс. в месяц. Часть из них — организационные, на них консультант почти не тратит времени. Но примерно половина требует реальной обработки. И из этой половины — около 40–50% вопросов повторяется снова и снова: разные клиенты задают одно и то же.
При этом все запросы стекаются в единую очередь, без приоритизации по сложности. Простой вопрос соседствует с многошаговой задачей по конкретному кейсу — и ждёт ровно столько же. В результате клиент с тривиальным вопросом может прождать несколько дней, потому что его запрос стоит за более сложным.
Это первая часть проблемы. Вторая — то, что внутри Айтона уже привыкли называть «фабрикой консультантов». Чтобы выйти на уверенный уровень и закрывать большую часть вопросов самостоятельно, новому консультанту нужно около полугода обучения. За это время он погружается в продукт, нарабатывает опыт по типовым кейсам, разбирается в терминологии. И вот здесь начинается экономическая часть боли: значительная часть выученных специалистов рано или поздно уходит в другие направления, и для заказчика этот шестимесячный цикл начинается заново — с нуля и без переноса контекста.
Получается замкнутая конструкция: огромный поток типовых вопросов, медленные ответы за счёт общей очереди, а под этим — постоянные вложения в людей, которые в итоге не остаются. И тут возникает закономерный вопрос: как к такой задаче подойти, чтобы не свалиться в очередное демо ради демо?
Принцип PoC: меньше функций, больше инфраструктуры
Первым логичным кандидатом на решение стал бот, который ориентируется в базе знаний и помогает консультанту быстро отвечать на типовые вопросы. Не замена консультанту, а инструмент снятия рутины. Но делать сразу полноценного агента для всех сценариев было бы слишком большим шагом: в таком проекте легко смешать проверку базовой гипотезы с десятком продуктовых доработок и потом не понять, что именно сработало, а что нет.
Поэтому решение мы сразу разделили на два этапа. Первый — прототип, по сути, проверка гипотезы: большая языковая модель плюс поиск по базе знаний дают ответы по 1С:УНФ на уровне, достаточном для использования консультантами в работе. Второй — развитие прототипа в полноценного агента: с историей диалога, обработкой скриншотов, уточняющими вопросами и дальнейшим выходом от внутреннего инструмента для консультантов к прямому каналу для клиентов.
Первый этап и был нашим PoC. Его принцип мы сформулировали так: не пытаться сделать маленькую версию всего будущего продукта, а проверить только центральную гипотезу. Поэтому мы сознательно исключили из прототипа всё, что явно понадобится дальше, но не влияет на ответ на главный вопрос:
историю диалога — она нужна для агента-консультанта, но к вопросу «работает ли вообще модель + поиск по нашей базе» отношения не имеет;
обработку скриншотов — в реальных диалогах их много, но в первом цикле проще обходиться текстом;
крайние случаи — отложили, чтобы не путать сигнал.
И намеренно вложились в то, без чего нельзя принять никакого решения:
валидационный датасет на основе реальных диалогов;
автоматические метрики качества по этому датасету;
мониторинг каждого запроса с первого дня.
Начинаем с данных, не с кода
Инженерный проект на больших языковых моделях начинается не с кода, а с данных. У нас на входе было два источника.
Первый — реальные диалоги службы поддержки из Telegram, несколько десятков тысяч сообщений от разных клиентов.
Второй — собственно база знаний: около 500 документов, инструкций, обучающих материалов и методических пособий, которыми пользуются сами консультанты.
Эти данные нам нужны были для двух разных задач.
Первая — понять, как именно задают вопросы, как консультанты отвечают, в каком стиле, где и в каком виде хранится информация для ответа. Этот анализ задаёт всё: как мы трансформируем материалы под поиск, как формулируем итоговый ответ, какие у нас будут крайние случаи.
Масштаб этого анализа стоит назвать в цифрах, потому что он показывает, сколько работы лежит до первой строчки кода. Из диалогов поддержки мы прогнали через анализ около 25 000 сообщений. Скользящим окном они свернулись в 618 окон контекста, из которых извлеклось 1 985 черновых пар «вопрос — ответ». Дальше — строгий отбор: оставляли только то, что относится к стандартному функционалу 1С:УНФ, без клиентских кастомизаций. После фильтра осталось 972 пары — 49% от извлечённого. Эти 972 пары — не датасет для оценки бота, а материал, по которому мы изучали, как пользователи реально формулируют запросы и в каком стиле отвечают консультанты.
Вторая задача — собрать валидационный датасет. На этапе прототипа у заказчика не было ни возможности, ни оснований выделять экспертов для ручной подготовки эталонных пар вопрос-ответ: это экспертное время, и без подтверждённой гипотезы тратить его рискованно. Поэтому датасет мы синтезировали сами. Из методички — отобрали стратифицированно по 20 темам, по 3–5 вопросов на тему, в стилистике и структуре, соответствующих реальным ответам консультантов. Получилось 110 пар «вопрос — эталонный ответ».
И здесь важная оговорка. Это не «наивная GPT-синтетика». Стиль вопросов мы заземлили на реальные диалоги: модель генерировала пары не «как ей вздумается», а с опорой на то, как пользователи реально формулируют запросы в поддержке. На выходе — вопросы в живом стиле и ответы из официального источника.
И здесь обычно начинают спорить, как именно нарезать чанки и какой реранкер выбрать. Мы пошли в другую сторону.
Простая архитектура и инфраструктура измерений
Вопросно-ответных систем на LLM сегодня делают много — это самый частый случай для тех, кто пробует продукты с языковыми моделями. И в индустрии регулярно встречаются две типичные ошибки.
Первая — с первого дня тащить максимально сложную архитектуру: гибридный поиск, переранжирование, суммаризация чанков, переформулировка запроса, многоступенчатые пайплайны. В итоге система получается такая, что непонятно, почему она дала именно этот ответ, и куда копать, если что-то идёт не так.
Вторая ошибка — оценка «на глаз»: ответы выглядят правдоподобно, в них есть знакомые слова из документов, и кажется, что всё хорошо. На реальной эксплуатации эта иллюзия рассыпается, а с чем разбираться — непонятно.
Поэтому я сразу выбрал противоположное: максимально простую RAG-цепочку плюс полноценный контур оценки качества.
Архитектура — без украшательств: пользовательский вопрос → поиск релевантных фрагментов в базе знаний → передача найденного и самого вопроса в языковую модель → ответ с указанием источников и степенью уверенности → доставка в Telegram-боте. На каждый ответ — кнопки «лайк» и «дизлайк», чтобы с первого дня собирать живой сигнал и формировать дополнительные датасеты на тех примерах, где результат пользователя не устроил.
Простота архитектуры — половина истории.
Вторая половина — измерительная инфраструктура. И в этом проекте она была не приложением к решению, а отдельным архитектурным элементом, без которого и решения-то нет.
Для мониторинга и трассировки мы взяли open-source-инструмент LangFuse. В нём — всё, что нужно: управление датасетами, проведение именованных экспериментов и сквозной мониторинг каждого запроса. Видно, что пришло на вход, какие фрагменты нашлись и с какими скорами, что ушло в промпт, какой получился ответ, сколько токенов и времени потратили на каждое звено. Это и есть «не чёрный ящик»: систему можно отлаживать по конкретным примерам, а не по ощущениям.
Поверх — Ragas. Это фреймворк со стандартными для RAG-систем метриками: насколько ответ опирается на найденные документы, насколько он попадает в суть вопроса, насколько он близок к эталону. На каждый прогон по датасету Ragas автоматически считает все метрики, и видно, что изменилось: подкрутили промпт — увидели сдвиг, поменяли параметры поиска — увидели другой сдвиг.
Главное в этом контуре — не сами цифры, а то, что мы начали измерять с первого дня, а не ждали финала, чтобы понять, работает ли вообще. Итерация «изменил — измерил» при таком устройстве стоит буквально копейки: один полный прогон оценки по всем метрикам на 110 вопросах обходился примерно в $1.54. За такую цену проверять каждое изменение промпта или параметров поиска — не подвиг, а дефолтный режим разработки.
Что говорят цифры и что подтвердил тест заказчика
Что в итоге дали измерения. Прогон по валидационному датасету из 110 пар:
Эти цифры стоит читать с поправкой на этап. Faithfulness около 0.8 для прототипа — хороший показатель: в большинстве случаев бот держится за источники, а не фантазирует. Answer Correctness 0.53 на первый взгляд выглядит слабо, но строгое совпадение с эталоном — самая жёсткая из метрик: часть ответов, которые она засчитала как «неточные», были корректными по смыслу, просто сформулированными иначе, чем эталон. Для проверки гипотезы «модель плюс поиск по нашей базе работают» этого набора значений достаточно — это не финальное качество продукта, а критерий «да, гипотеза держится, идём дальше».
Этого было бы достаточно, если бы задача была просто отчитаться. Но измерения, какими бы аккуратными они ни были, остаются нашими собственными — а гипотеза проверяется ещё и независимым взглядом.
Тут помогла внутренняя практика самого заказчика.
У Айтона есть тест для приёма консультантов на работу: набор вопросов, которые проверяют компетенции нового специалиста перед выходом на линию. Заказчик предложил его как дополнительный критерий успеха PoC — фактически как экзамен для бота. Мы скормили боту все вопросы из этого теста, и он ответил на каждый успешно. То есть в момент окончания первого этапа бота можно было — формально по критериям заказчика — «принимать на работу» консультантом.
Получается двойное подтверждение: метрики сказали — работает, заказчик проверил собственным тестом — подтвердил. Гипотеза держится, проект жизнеспособен, идём дальше. Но «дальше» — это не «отдать пользователям как есть».
Где гипотеза заканчивается, а реальность начинается
Когда консультанты начали применять бот в реальных рабочих сценариях — не на синтетическом датасете, а на потоке живых вопросов, — обнажились случаи, которые наш прототип не закрывал. Их оказалось пять, и важно вот что: ни один из них не стал сюрпризом.
Два мы осознанно отложили на старте, чтобы не путать проверку гипотезы. Это многошаговый диалог — когда вопрос идёт в контексте предыдущих, а бот каждый раз отвечает «с нуля», как будто история не существует. И скриншоты — типовая практика пользователей: проще скинуть картинку с формой и подписью «на что влияет этот флаг», чем словами описывать, какое именно поле в каком документе имеется в виду.
Остальные три предсказал анализ данных ещё на этапе работы с диалогами. Терминологическая неоднозначность. В предметной области 1С много многозначных слов: «счёт» — это бухгалтерский счёт или счёт на оплату; «возврат» — товара, оплаты, поставщику; «учёт» и «себестоимость» — десятки контекстов. Без уточнения, что именно имеет в виду пользователь, корректно ответить нельзя, а пытаться «угадать» — означает регулярно мимо.
Несуществующий функционал. Часть запросов — про возможности, которых в 1С:УНФ просто нет. Здесь бот ни в коем случае не должен «придумывать»: нужен аргументированный ответ, что такой функции нет, и при возможности — указание на альтернативу. Это отдельный сюжет, потому что аргументация требует не только базы знаний, но и внешнего контекста.
Пробелы в базе знаний. Методические материалы у заказчика подробные, но покрывают не всё, что реально спрашивают пользователи. У Айтона при этом много неструктурированных источников — записи лекций, вебинаров, семинаров. Возникает естественный вопрос: можно ли такие материалы аккуратно подключить так, чтобы они расширяли область знаний без потери качества по тому, что уже покрыто.
«Ни один не стал сюрпризом» здесь — не самореклама. Это эффект того, что на этапе PoC мы серьёзно вложились в анализ данных: всё перечисленное либо лежало в плане как «отложено», либо предсказывалось распределением вопросов и стилем диалогов. Это и есть нормальный итерационный цикл — не провал прототипа, а дорожная карта.
И вот здесь становится очевидно, что классический RAG-пайплайн эти сценарии уже не закрывает. Нужен следующий шаг.
Когда прямого RAG уже мало: переход к агенту
Прямой RAG-пайплайн детерминированный: у него один путь и одна задача. Получил вопрос — нашёл документы — сгенерировал ответ. Он не рассуждает, не выбирает между альтернативами, не уточняет, не помнит. А консультанту нужно вести себя как настоящий специалист: проанализировать запрос, понять, что именно имеет в виду пользователь, выбрать подходящий способ ответить — поискать в базе, уточнить контекст, проверить во внешних источниках, — и при этом помнить весь предыдущий диалог.
Все эти свойства — способность рассуждать и действовать автономно — и образуют то, что в индустрии называют агентом. В нашем случае это была не смена шильдика над архитектурой ради хайпа, а конкретный технический ответ на конкретные сценарии, которые я перечислил выше. Опорой служит модель с поддержкой рассуждений — сейчас таких достаточно и среди проприетарных, и среди открытых, так что вопрос «есть ли надёжная база» уже не стоит.
Из чего состоит агент. Три компонента.
Первый — память. Это история диалога плюс работа с этой историей, то есть context engineering. Как только история начинает занимать длинные хвосты, упирается в размер контекстного окна модели, и приходится управлять им осмысленно. Здесь хватает двух приёмов: обрезать хвост, чтобы не переполнять окно, и суммаризировать выкинутое, чтобы не терять смысл предыдущих ходов. Без памяти бот вообще не консультант — он каждый раз отвечает «как будто видит вопрос впервые».
Второй — системный промпт, то есть инструкции для модели. Это та часть, которую делающие агенты часто недооценивают. В RAG-пайплайне промпт тоже был, но там он работал в узкой роли — «ты ассистент, делай вот это». В агенте системный промпт несёт куда больше: через него — следуя той же логике «делай просто, не делай сложно» — закрываются и понимание терминологии предметной области, и правила, когда уточнять, а когда сразу отвечать, и базовая безопасность (не отвечать на нерелевантные запросы, не вестись на попытки взлома). Часть задач, которые на первый взгляд кажутся архитектурными, на деле решается аккуратной настройкой инструкций, без раздувания набора инструментов.
Третий — инструменты. И вот здесь принципиальное смещение: RAG, то есть поиск по базе знаний, теперь — один из инструментов агента, а не вся система. Скриншоты — тоже отдельная «способность», но без излишнего усложнения: современные модели поддерживают мультимодальность напрямую, и изображение уходит как часть контекста, без отдельного OCR или специально написанного описателя. Поиск во внешних источниках — отдельный инструмент-эксперт, к нему я ещё вернусь. И, что важно, агент сам решает, как использовать каждый инструмент. Тот же RAG он может вызвать несколько раз с переформулировкой: посмотреть на вопрос, выделить значимые элементы, сформировать поисковое выражение, проанализировать результаты — и при необходимости пройти по этой цепочке ещё раз. Архитектура за это ничего не платит: больше не надо «прибивать гвоздями» отдельные ветки логики.
Разница двух архитектур
Разницу двух архитектур проще всего увидеть на одном вопросе. Возьмём запрос из реальной практики: «как сделать возврат?». Слово «возврат» в 1С:УНФ многозначно — это может быть возврат товара от покупателя, возврат денег, возврат поставщику.
Прямой RAG отрабатывает его буквально: берёт текст «как сделать возврат», ищет по базе знаний наиболее похожие фрагменты и генерирует ответ по тому, что нашлось. Если в выдачу попали документы про возврат товара — ответ будет про возврат товара, даже если пользователь имел в виду возврат денег. Цепочка одна, развилки в ней нет.
Агент на том же вопросе ведёт себя иначе. Он сначала рассуждает: вопрос неоднозначный, по нему нельзя дать один корректный ответ. Дальше он решает не идти сразу в поиск, а задать уточняющий вопрос — «возврат чего именно: товара, оплаты или поставщику?». Получив уточнение, он формирует уже точное поисковое выражение, при необходимости вызывает поиск по базе несколько раз с переформулировкой, проверяет результаты — и только потом отвечает. Тот же вопрос, та же база знаний, но между запросом и ответом появился контур принятия решений.
Тот же цикл, новые задачи
Дальше — самая интересная часть инженерной дисциплины. Каждый из пяти сценариев мы проходили по той же цепочке, что и сам PoC: анализ реальных диалогов → синтез датасета под конкретную задачу → подбор метрик → решение → измерение. Меняется содержание, не меняется метод. Это и есть инвариант — измерения раньше архитектуры.
Несколько важных уточнений по самому процессу. На этом этапе датасет уже не должен и не может быть полностью синтетическим: речь не о проверке гипотезы, а о переходе к промышленной эксплуатации, сначала консультантам в качестве внутреннего инструмента, потом клиентам. Поэтому датасеты теперь готовятся и валидируются представителями заказчика — экспертами предметной области, — и далее сопровождаются. Реальные пользователи задают реальные вопросы, появляются новые сценарии или края — это всё должно подтягиваться в датасет, прогоняться и проверяться.
Что вышло по каждому сценарию.
Многошаговый диалог — закрыли памятью и работой с контекстом поверх неё — это и есть context engineering: история сохраняется в рамках сессии, при приближении к границе окна — обрезается с суммаризацией предыдущих ходов.
Скриншоты — отдали мультимодальной модели напрямую. Никаких отдельных пайплайнов с OCR и описаниями: пользователь скидывает изображение вместе с вопросом, модель учитывает его как часть контекста и формулирует ответ.
Агент видит скриншот: вопрос привязан к конкретному элементу формы Терминология и уточняющие вопросы — реализованы через системный промпт, а не через отдельный инструмент. Уточняющий вопрос — это обычное сообщение агента, не требующее особой механики; принципиально лишь правило: уточнять только когда ответ без контекста действительно был бы бесполезным.
Агент уточняет: неоднозначный термин лучше прояснить, чем угадывать Несуществующий функционал — отдельный суб-агент. Он работает в случае, когда в нашей базе знаний материалов нет: выполняет поиск в открытых источниках, анализирует результаты и формирует аргументированный вердикт — либо «функции действительно нет, и вот почему», либо «вот как это реально решается, ссылки прилагаются», нередко с альтернативой.
Пробелы в базе знаний — расширение через транскрипции видеоуроков. Здесь мы провели контролируемый эксперимент: взяли часть датасета, которая покрывается старой базой знаний, и проверили, что качество ответов на этих вопросах не ухудшилось; и отдельно собрали датасет вопросов, по которым информации в существующих инструкциях нет, — «дельту», чтобы понять, действительно ли расширенная база теперь на них отвечает. Эксперимент подтвердил, что такие неструктурированные источники можно использовать.
Как измеряли агентные действия
Под все эти сценарии нужно было расширить и сам измерительный контур.
Базовые метрики RAG-системы никуда не делись — она же по-прежнему отвечает на вопросы. Но прямой RAG отвечал одним движением, а агент рассуждает, выбирает инструмент, уточняет — и каждое из этих действий нужно измерять отдельно. Поэтому поверх стандартного набора Ragas добавились метрики двух новых групп.
Первая — метрики извлечения: насколько часто нужный документ вообще попадает в выдачу поиска (Hit Rate@k) и на какой позиции он оказывается (MRR).
Вторая — собственные агентные метрики, которых в готовых фреймворках нет:
точность выбора инструмента — пошёл ли агент в базу знаний, в веб-поиск или верно решил ответить по уже имеющемуся контексту;
корректность использования инструмента — насколько удачно агент сформулировал поисковое выражение; для сопоставления фактических вызовов инструментов с эталонными у нас своя метрика мягкого совпадения,
FuzzyToolCallF1;уместность уточняющих вопросов —
clarification_accuracyпо тернарной шкале: задал уточнение там, где надо (1.0); задал, но не той категории (0.5); не задал, хотя был обязан (0);корректность вердикта про отсутствующий функционал —
verdict_l1_accuracy: правильно ли суб-агент классифицировал случай как «функция есть», «функции нет» или «не знаю».
Каждая группа метрик прогоняется на своём датасете: основной вопросно-ответный rag_itone_qa (те самые 110 пар), отдельный набор clarifying_itone (27 диалогов под уточняющие вопросы) и no_feature_itone (75 примеров про несуществующий функционал). Критерий успеха здесь был сформулирован как двойное условие: новые агентные метрики должны выйти на рабочий уровень, и при этом базовые RAG-показатели не должны просесть — агент не имеет права стать хуже в том, что прямой RAG уже умел. Оба условия выполнились: агентное поведение измеримо работает, а метрики качества ответа на основном датасете остались на уровне PoC.
Одна история из этого этапа стоит того, чтобы её рассказать отдельно.
Эксперт со стороны заказчика готовил датасет под уточняющие вопросы — набор реальных кейсов, на которых мы прогоняли поведение агента. Прогоняем — метрика плохая. Смотрим, в чём дело: агент не задал уточнение, а сразу ответил. Идём к эксперту: «вот ответ, нам он выглядит корректным». Эксперт смотрит — да, действительно корректный. Просто из самого вопроса можно было извлечь все нужные тонкости и однозначно сложить ответ, не задавая дополнительных вопросов. То есть модель — а в финальной версии агента у нас под капотом Gemini 3.1 Pro, на прототипе была одна из моделей OpenAI, — посмотрела на вопрос и увидела ответ там, где эксперт видел развилку. В итоге кейс ушёл из датасета для уточнений: уточнения здесь не требуется. Плохая метрика была плохой не потому, что агент ошибся, а потому что модель превзошла ожидания.
И ещё пара технических деталей, которые имеет смысл назвать, чтобы было понятно, на чём всё собрано.
Сам агент реализован на фреймворке LangChain 1.0 , где сильно удобнее устроены инструменты и middleware hooks, через которые можно врезаться в агентский цикл в любом месте: ставить фильтры, проверки безопасности, дополнительные обработчики.
По LLM: вместе с Gemini тестировались и открытые модели среднего масштаба — gpt-oss-120b, Qwen — на случай требований по запуску в закрытом контуре заказчика; на агентных сценариях они показали сопоставимое качество.
Персональные данные в нынешней базе знаний не фигурируют — это общая информация о продукте; на следующих итерациях, когда речь зайдёт о подключении кастомных доработок конкретных клиентов, планируется фильтрация и подстановка значений перед отправкой во внешнюю модель с возможностью восстановить контекст уже после ответа.
Ремарка про AI-driven development
Если интересен не только сам агент, но и то, как он разрабатывался, то этот кейс целиком шёл по AI-driven методологии.
В качестве основной среды я использовал Cursor: кодовые агенты брали на себя реализацию, рефакторинг, тесты и рабочие скрипты, а моя часть оставалась в постановке задачи, проверке архитектурных решений, работе с данными и оценке качества.
Из полезной обвязки вокруг разработки: MCP-серверы Context7 и Docs by LangChain для быстрого доступа к актуальной документации, плюс отдельные LangFuse-навыки для анализа датасетов, трейсов и результатов eval-прогонов.
Что работает сегодня и что получилось в итоге
Пока статья готовилась к публикации, агент прошёл ещё один важный шаг. Сначала он отработал стадию внутреннего тестирования, потом режим ассистента для сотрудников Айтона, а теперь выведен наружу как клиентский сервис — с биллингом, собственной монетизацией и прямой пользой для клиентов. Об этой части, где AI-агент становится уже не внутренним инструментом, а отдельным сервисом с экономикой, я расскажу отдельно.
При этом измерительный контур никуда не исчез: LangFuse трассирует запросы, Ragas прогоняет оценку, датасеты сопровождаются и пополняются на тех сценариях, где живой поток это просит.
И самое заметное изменение — не в скорости ответа клиенту, хотя она тоже выросла. Заметнее изменилась практика самих консультантов. Раньше менее опытный сотрудник, получив непривычный вопрос, шёл к более опытному, забирал его время на «к каким материалам обратиться, что важно учесть» и потом отдельно ещё разбирался сам. Сейчас работает примерно по модели Perplexity: ответ приходит сразу, и дополнительными вопросами можно проваливаться вглубь — переспрашивать, уточнять, разворачивать тему. Бот выступает в роли ментора, и обучение идёт гораздо быстрее, чем по методичкам.
Итоговый чек-лист
И возвращаясь к тому, с чего я начал. Этот путь — от RAG-прототипа до агента в продакшне — мы прошли не выбором модной архитектуры, а последовательностью инженерных решений, в каждом из которых данные и метрики стояли раньше схемы. Сначала ограниченный PoC с дисциплиной измерений. Потом — пять сценариев, которые показала реальная эксплуатация. И только под эти сценарии — следующий архитектурный шаг, агент. Уберите инженерный слой, оставьте только хайповую обвязку, и получится дорогая игрушка, какой я тоже видел немало. Сохраните инженерный слой — и получится система, которой действительно пользуются.
Если вы строите похожего агента, порядок шагов из этого кейса можно свернуть в короткий маршрут — он же показывает, в каком месте обычно соблазн срезать угол:
начните не с кода, а с данных — реальные диалоги пользователей и база знаний показывают, как на самом деле задают вопросы и что вообще есть для ответа;
соберите валидационный датасет и поднимите измерительный контур (мониторинг каждого запроса плюс автоматические метрики) до того, как писать функциональность;
сделайте первым шагом максимально простой RAG — задача прототипа ответить «да или нет», а не выглядеть как продукт;
проверьте гипотезу не только своими метриками, но и независимым критерием — тестом или приёмкой со стороны заказчика;
выпустите прототип на реальных пользователей и соберите сценарии, которые он не закрывает, — это и есть дорожная карта;
и только под эти сценарии добавляйте память, мультимодальность и инструменты — расширяя вместе с архитектурой и сам измерительный контур.
Каждый шаг здесь держится на предыдущем: без данных нет датасета, без датасета нечем мерить, без измерений непонятно, нужен ли вообще следующий архитектурный шаг.
А у вас порядок шагов был такой же — или вы заходили с другого конца? Где в собственном проекте появлялся самый сильный соблазн срезать угол, и что в итоге его держало? Расскажите в комментариях.
Мы рассмотрели реальный кейс от идеи до продакшна: не через «прикрутили LLM», а через данные, метрики, качество и постепенное усложнение архитектуры.
В LLMStart.ru мы помогаем бизнесу решать такие задачи и получать реальный эффект от ИИ — от прототипа до промышленной эксплуатации. Если вам близок такой подход, обращайтесь, будем рады обсудить вашу задачу.
Если хотите перенять опыт и научиться делать подобные системы самостоятельно, у нас есть онлайн-курсы, а ближайший живой поток курса Deep Agents стартует уже в четверг, 28 мая.