Этот слой вырос из четырёх внедрений, где снова и снова повторялась одна работа: вытащить правила из документов и чатов, поднять похожие реальные кейсы и до релиза увидеть, где агент всё ещё действует по старому сценарию.
На одном проекте 47% правок выросли из живых диалогов. На другом корпоративный тон шлифовали больше 60 итераций. На третьем формула уверенности доросла до 30+ параметров. На четвёртом понадобились отдельные наборы проверки для каждого промежуточного шага.
После нескольких внедрений стало видно одно и то же: модель и RAG поднимаются быстро. Дорогая часть начинается позже, когда нужно собрать правила из PDF, DOCX, таблиц и чатов, превратить реальные ошибки в проверочные кейсы и не пересобирать всё заново после каждой смены сценария или контракта. Из этой повторяющейся работы и вырос datasetgen.
Общая карта платформы — на обзорной странице →
Пациент пишет в ДМС-чат: «Нужно МРТ, удобно завтра после обеда». До вчерашнего дня агент мог сразу готовить запись в клинику. Теперь по программе для таких случаев сначала обязателен телемед, а гарантийное письмо нельзя выпускать до этого шага.
Без такого слоя это изменение живёт в PDF, переписке с бизнесом и в голове аналитика. Агент при этом легко продолжает часть сценариев по старому маршруту: пытается записать пациента сразу или слишком рано готовит гарантийное письмо.
Datasetgen забирает новое правило, поднимает похожие реальные чаты и собирает из них набор проверки: где запись можно делать сразу, где нужно остановиться на телемеде, где обращение должно уйти оператору.
После этого команда прогоняет новый вариант агента по этому набору и получает не абстрактный “контур качества”, а конкретный список сценариев, где агент всё ещё путает маршрут, клинику или момент выпуска гарантийного письма.
Каждый блок начинался как костыль на конкретном внедрении и дорастал до переиспользуемого механизма.
В инвестиционном проекте 47% правок выросли из живых диалогов. Стало ясно, что обращения из продакшна нужно превращать в новые правила и проверочные кейсы, а не разбирать постфактум на созвонах.
В телекоме корпоративный тон и формулировки шлифовали 60+ итераций. Понадобился переносимый способ фиксировать сценарии и проверять качество после каждой правки, а не собирать этот контур заново.
На транспортном проекте формула уверенности доросла до 30+ параметров, а каждый штраф появился после конкретного провала. Это показало, что ошибка часто живёт в данных и проверках ещё до модели.
В ДМС-процессе пришлось держать отдельные наборы проверки на чат, услугу, визит, заметки и OKK. Один итоговый балл оказался бесполезен, потому что ошибки прятались внутри промежуточных шагов.
Мы вытаскиваем требования из документов, таблиц, схем и примеров, чтобы у команды было одно место с правилами, ограничениями и граничными случаями.
Набор привязан к конкретной схеме входа и выхода, типам сценариев и границам, которые должен выдержать агент. Общий «датасет для домена» здесь бесполезен.
Корректный YAML или JSON — необходимый минимум. За ним стоят покрытие требований, негативные и граничные кейсы, противоречия в ожидаемом результате и признаки деградации.
Когда меняется схема агента или сам сценарий, мы стараемся не собирать всё заново. Наборы точечно правятся, дополняются и по возможности переносятся на новый контракт.
Файл на выходе получить легко, а вот добиться, чтобы ожидаемый результат отражал реальную логику процесса и скрытые ограничения, — это уже другая работа. Правдоподобный на вид датасет обманывает всех, включая команду.
Самая трудная часть — перевести профессиональное суждение аналитика, QA и оператора в поля, негативные кейсы, допуски и проверяемые сценарии. Обычная настройка open source до этого места не дотягивает.
Эта работа никогда не заканчивается: документы меняются, агент получает новый контракт, сценарии расширяются. Значит, наборы проверки и сам контур качества тоже нужно обновлять, а не выбрасывать после каждой правки.
Datasetgen уже встроен в платформу — это связка трёх модулей с общей карты.
Главный контур: синтетические и проверочные наборы, LLM-судьи, регрессии и контроль деградации после изменений.
Вход в контур: документы, таблицы, методики и примеры собираются в единое описание правил для генерации и проверки.
Процессы бизнес-анализа и QA поверх агентной среды: сбор контекста, нормализация требований, подготовка наборов и точечные правки после изменений.
На новом проекте команда не начинает с нуля сбор требований и проверочных наборов. Повторяющиеся шаги уже упакованы, механическая сборка артефактов остаётся внутри, и время уходит на доменную специфику.
После изменений в агенте или документах не приходится вслепую пересобирать весь контур качества. Можно точечно обновлять наборы и отдельно проверять, что именно сломалось.
После изменения агента клиент получает обновлённые правила, набор проверки и отчёт, какие сценарии больше не проходят.
Четыре внедрения, из которых вырос этот слой, — на странице кейсов. Смотреть кейсы →
Ответим, подходит ли задача для AI-агентов, и если да, предложим конкретный план.
Заявка отправлена
Ответим в течение дня на указанный email.
или напишите напрямую — ilya@manaraga.ai