Инженер СберТеха Дмитрий Титов описал, как команда Platform V Synapse победила одну из самых раздражающих рутин в enterprise-разработке: ручное составление конфигурационных файлов для системы потоковой обработки событий. Продукт обрабатывает миллионы событий в секунду, у него собственный декларативный DSL — и 200-страничная документация к нему. Раньше создание одного конфига занимало от 30 минут до нескольких часов. Теперь — около 30 секунд.
Контекст
Platform V Streaming Event Processing — это enterprise-решение СберТеха для фильтрации, трансформации, агрегации и анализа событийных потоков в реальном времени. Источники данных — Kafka, RabbitMQ/ArtemisMQ, GRPC, PostgreSQL. Правила обработки задаются через собственный DSL (так называемые tr-файлы) — декларативный язык, которого нет в публичных обучающих данных никакого LLM. Ни GigaChat, ни Claude, ни другие модели просто не видели этого синтаксиса. Результат при попытке «угадать» — галлюцинации: несуществующие функции, перепутанный порядок секций, синтаксис от других языков.
Классический workflow инженера выглядел так: открыть документацию на 200+ страниц, найти нужный раздел про Kafka или PostgreSQL, вспомнить или отыскать синтаксис DSL, скопировать похожий конфиг из корпоративного Git и вручную подогнать под задачу. Переключение между вкладками, потеря контекста, опечатки в именах параметров — и итоговое время на одну задачу средней сложности могло легко перевалить за час.
Проблема усугублялась тем, что документация живая: параметры добавляются, часть уходит в deprecated, меняются рекомендации. Инженер, копирующий старый конфиг, мог не знать об этих изменениях и тащить устаревшие паттерны в production.
Аналитика
Ключевое архитектурное решение здесь — RAG как не улучшение, а обязательный компонент. Без доступа к актуальной документации LLM в принципе не может корректно генерировать конфигурации на проприетарном DSL. Это честная постановка задачи: модель — не источник знаний, а интерпретатор документации. Она понимает запрос пользователя и правильно применяет найденные фрагменты. Разница тонкая, но принципиальная для любой команды, работающей с внутренними форматами, стандартами или закрытыми API.
Второй слой — мультиагентное взаимодействие по протоколу A2A. Агент-генератор создаёт конфигурацию, агент-валидатор проверяет её на соответствие исходному запросу, наличие обязательных параметров, логические ошибки и проблемы с производительностью. Итеративный цикл занимает 1–3 прохода и полностью автоматический. Это пример production-ready agentic-архитектуры, где агенты решают не «поговорить», а довести артефакт до валидного состояния. Такой паттерн — generator + critic — начинает встречаться в enterprise всё чаще именно потому, что он решает проблему галлюцинаций на выходе без участия человека в контуре.
С точки зрения трендов: статья иллюстрирует сдвиг от «давайте подключим LLM к интерфейсу» к «давайте перепроектируем рутинный процесс под AI-first исполнение». Экономия не в 10%, а в 30–60 раз по времени на задачу — это уровень, при котором автоматизация меняет структуру рабочего дня инженера реально, а не на бумаге.
Кейсы применения в бизнесе
B2B-SaaS стартап с собственным форматом конфигов или внутренним DSL. Если у вас есть хотя бы 50–100 страниц внутренней документации и команда регулярно создаёт конфиги, манифесты или шаблоны — паттерн RAG + валидирующий агент окупается быстро. Векторизировать документацию, настроить семантический поиск, добавить агента-критика — это несколько дней работы, а не месяцев. Ожидаемый эффект: снижение времени на рутинные DevOps-задачи в 10–30 раз, меньше ошибок в production.
Корпорация с legacy и объёмной внутренней документацией. Именно такой кейс описан в статье. Если документация существует в Markdown или Confluence — её можно векторизировать напрямую. Чанки по 256–512 токенов с перекрытием 10–20%, модель эмбеддингов, адаптированная под язык документации (для русского — важно). Критически важно: обновлять векторную базу при каждом изменении документации, иначе модель будет генерировать конфиги по устаревшим схемам.
SMB и локальный бизнес в КР/СНГ, работающий с повторяющимися шаблонными документами. Договоры, акты, технические задания, брифы — если у вас есть типовые документы с вариабельными параметрами и внутренний стандарт заполнения, тот же подход работает. Описываешь задачу на естественном языке, система находит нужный шаблон и его спецификацию, генерирует заполненный документ, валидатор проверяет обязательные поля. Инструменты — открытые: ChromaDB или pgvector для хранения эмбеддингов, любой доступный LLM через API.
Кейсы в личной жизни
Разработчик, работающий с несколькими форматами конфигов (k8s, docker-compose, CI/CD). Векторизируй официальную документацию Kubernetes, GitHub Actions, Terraform — и получи персонального ассистента, который генерирует корректные манифесты по описанию задачи. Не абстрактную заготовку из Stack Overflow, а конфиг под твой конкретный кейс с учётом актуальной версии спеки.
Контент-мейкер или фрилансер, работающий по повторяющимся брифам. Если у тебя накоплена база выполненных проектов или внутренних стандартов — векторизируй её. Описываешь новый проект в свободной форме, система находит похожие кейсы и генерирует черновик брифа, структуры проекта или коммерческого предложения с учётом твоих паттернов.
Студент или исследователь, работающий с объёмными источниками. RAG — это и есть то, что делает «умный» поиск по PDF-учебникам или диссертациям. Загружаешь корпус, задаёшь вопрос или просишь сгенерировать раздел — система тянет релевантные фрагменты и собирает ответ с опорой на конкретные части текста. Это честнее, чем просто промптить модель по памяти.
Как применить сегодня
- Шаг 1: Векторизируй свою документацию. Возьми внутренние Markdown-файлы, Confluence-выгрузку или PDF. Нарежь на чанки по 300–500 токенов с перекрытием ~15%. Используй pgvector (если уже есть Postgres) или ChromaDB для хранения эмбеддингов. Для русскоязычных текстов — выбирай модель эмбеддингов, обученную на русском.
- Шаг 2: Настрой семантический поиск с топ-K=3–5. Не больше: лишний контекст запутывает модель и увеличивает стоимость запроса. Добавь фильтрацию по метаданным (тег, раздел, дата обновления) — это резко повышает точность.
- Шаг 3: Напиши строгий system prompt для агента-генератора. Ключевой паттерн из статьи: «используй только информацию из переданного контекста», «не придумывай параметры», «не добавляй комментариев». Это сильно снижает галлюцинации на проприетарных форматах.
- Шаг 4: Добавь агента-валидатора по паттерну A2A. Валидатор получает сгенерированный артефакт и исходный запрос, проверяет соответствие, возвращает список замечаний или подтверждение. Генератор исправляет. Обычно 1–3 итерации до валидного результата.
- Шаг 5: Обнови пайплайн обновления документации. RAG полезен ровно настолько, насколько актуальна векторная база. Настрой автообновление при каждом коммите в репозиторий с документацией.