Привет! На связи Валера Ковальский — руководитель направления искусственного интеллекта в red_mad_robot. В работе с AI-инфраструктурой мы постоянно тестируем различные подходы, чтобы создавать решения с реальной бизнес-ценностью.
В этой статье расскажу, как мы решаем задачи при внедрении AI-агентских систем: от классического RAG до сложных мультиагентных решений. Также поделюсь, с какими проблемами сталкиваемся при работе с большими данными — и как находим эффективные пути их решения.
Почему традиционные LLM-системы недостаточно эффективны для сложных бизнес-задач
Неспособность понять комплексные запросы
Классические LLM-системы хорошо справляются с простыми задачами, но испытывают трудности при многозадачных и технически сложных запросах.
Например, мы тестировали RAG на технической документации по Manticoresearch. Документация была разбита на чанки и загружена в векторную базу данных. Для извлечения использовали подход parent document extraction — вместе с релевантными чанками извлекался весь раздел документа.
Запрос: «Покажи, как оформить JSON для выполнения операции replace в KNN-колонках RT-индекса, где поле называется embedding, и пришли пример Python-запроса.»
Такой запрос требует одновременно:
Понимания множества взаимосвязанных технических концепций
Интеграции информации из разных частей документа
Генерации корректного кода
Точности в деталях реализации
Система не справилась — становится понятно, что её нужно усложнять и делать более гибкой для многосоставных запросов. Это достигается добавлением таких элементов, как router agent, разбиение на домены и query expansion.
Потеря контекста при разбиении документов
Стандартный подход, где используется RAG также теряет важные связи при разбиении документов на чанки, из-за чего ответы становятся некорректными или поверхностными. А это критично для технических систем, где все концепции взаимосвязаны.
Типичный ответ стандартного пайплайна Naive RAG: «Для работы с KNN-колонками используйте метод X…»
Naive RAG — самый простой пайплайн без дополнительных обработок: он использует только векторное пространство и одиночный KNN-запрос к индексу.
Модель игнорирует контекст: не учитывает, что речь идёт о RT-индексах, специфике операций replace, поле embedding и необходимости сгенерировать корректный Python-запрос. LLM не разобрала наш запрос и не собрала нужный контекст, а использовала только то, что получила от retrieval-функции, без дополнительной проверки.
Непонимание языка конкретной технической области
Ещё одна проблема — недостаточное понимание специфического языка технической области. Особенно, если это касается данных которые не были в обучении. LLM нужно «научить говорить» на языке конкретной технической документации: знать, что именно в этой системе скрывается под термином embedding, какие методы актуальны для поиска, как устроены поля и ограничения.
Например, если спросить, как добавить векторные данные и сделать поиск по ним, стандартный RAG выдаст общее описание: «используйте векторную базу данных, загрузите эмбеддинги, примените косинусное сходство». Без учёта того, как это реализуется в конкретной системе, какие типы индексов она поддерживает, какие форматы принимает и как структурировать запрос.
Без адаптации под домен и документацию Naive RAG работает как справочник по теории, но не как помощник, способный дать рабочее решение.
Сложность объединения разрозненной информации
Кроме того, стандартный RAG плохо объединяет разрозненную информацию из нескольких разделов документации. Он не умеет правильно комбинировать данные из разных частей, что приводит к неполным или противоречивым ответам.
Запрос: «Какие ограничения есть у RT-индексов при работе с JSON-полями и векторами одновременно?»
Модель должна объединить сведения о трёх разных элементах: RT-индексах, JSON-структурах и работе с векторами. Однако традиционный RAG ищет ответ в ближайших чанках и не способен распознать, что нужная информация распределена по разным разделам. В итоге он может выдать частичный или противоречивый ответ, игнорируя важные нюансы, такие как несовместимость типов данных или ограничения на одновременное использование фичей.
Подобные проблемы возникают не только в технической документации. Ещё сложнее ситуация становится, когда система работает с большими объёмами разнородной информации, относящейся к разным сущностям или продуктам. В таких случаях недостаточно простого улучшения RAG-подходов — необходима принципиально другая архитектура работы с данными и знаниями.
Доменное разделение знаний или единый домен: как архитектура AI-системы влияет на бизнес-результат
Ошибки, возникающие из-за некорректного проектирования архитектуры знаний, перестают быть просто технической проблемой — они начинают напрямую влиять на эффективность бизнеса. Особенно остро это проявляется в отраслях с большим объёмом разнородной информации, где даже незначительное смешение данных может привести к финансовым потерям, снижению доверия клиентов и репутационным рискам.
С такой ситуацией мы столкнулись на проекте для девелопера ФСК. В ранней версии системы вся информация о жилых комплексах была объединена в единый домен знаний. Такой подход казался логичным — один продукт, один набор данных.
Но на практике он вызвал проблемы: система начала путаться в деталях, информация о разных ЖК смешивалась, снижалась точность ответов, возникали ошибки в ценах и сроках сдачи. При сложных вопросах модель начинала «галлюцинировать». Всё это происходило из-за отсутствия границ между потоками знаний. Один запрос мог затрагивать несколько объектов, и модель не понимала, о каком именно идёт речь.
Решение: router agent
Мы переработали архитектуру и вместо единого домена внедрили структуру с изолированными областями знаний — по одному на каждый жилой комплекс. Ключевой элемент — router agent — анализирует пользовательский запрос, определяет, о каком объекте речь, и направляет его в нужный домен. Если в запросе упоминается несколько ЖК, агент собирает информацию из разных источников и формирует объединённый ответ.
Результаты
Точность ответов выросла с 76% до 94%
Время обработки запросов снизилось на 35%
Критические ошибки в информации были полностью исключены
Этот кейс показал, насколько важны правильная структура знаний и чёткая маршрутизация запросов — даже если речь идёт о данных внутри одной компании. Универсальные подходы здесь не работают: нужна осознанная архитектура, учитывающая специфику предметной области.
Как технически эффективно решать эти проблемы?
При работе с техническими и многослойными запросами стандартного RAG уже недостаточно. Требуется более продуманный и системный подход, который включает несколько ключевых элементов.
1. Стратегия разметки и индексации документации: документы должны быть структурированы с учётом иерархии и логических связей между разделами. Это помогает избежать потери контекста при извлечении информации и позволяет агенту «понимать», как устроен материал.
2. Механизмы Chain of Thought (CoT): модель должна не просто выдавать финальный ответ, а последовательно выстраивать логическую цепочку рассуждений — особенно в задачах с несколькими зависимостями или условиями.
{
"type": "object",
"properties": {
"reasoning": {
"type": "object",
"properties": {
"query_analysis": {
"type": "object",
"properties": {
"user_query": {"type": "string", "description": "The original user query"},
"query_interpretation": {
"type": "string",
"description": "Analysis of what the user is asking for",
},
},
"required": ["user_query", "query_interpretation"],
},
"information_search": {
"type": "object",
"properties": {
"search_strategy": {
"type": "string",
"description": "Description of how relevant information was searched across documents",
},
"relevant_documents": {
"type": "array",
"items": {
"type": "object",
"properties": {
"document_name": {"type": "string", "description": "Name of the document"},
"pages": {
"type": "array",
"items": {"type": "integer"},
"description": "Page numbers containing relevant information",
},
"relevance": {
"type": "string",
"description": "Why this document is relevant to the query",
},
},
"required": ["document_name", "pages", "relevance"],
},
"description": "List of relevant documents and pages",
},
},
"required": ["search_strategy", "relevant_documents"],
},
},
"required": ["query_analysis", "information_search"],
},
"response": {
"type": "string",
"description": "Complete answer to the user query based on the found information."
},
"sources": {
"type": "array",
"items": {
"type": "object",
"properties": {
"document_name": {"type": "string", "description": "Name of the document"},
"pages": {"type": "array", "items": {"type": "integer"}, "description": "Page numbers used"}
},
"required": ["document_name", "pages"],
},
"description": "List of all sources used with page numbers",
},
},
"required": ["reasoning", "response", "sources"],
}3. Query expansion: агент должен уметь дополнять пользовательский запрос за счёт внутренних знаний или контекста, если исходная формулировка неполна. Это особенно важно в технической документации, где многие термины и параметры могут быть опущены «по умолчанию».
4. Оптимизация контекста: при генерации ответа важно учитывать взаимосвязи между частями документа, а также их положение в общей структуре (например, «ограничения» могут находиться в отдельном разделе от описания методов).
5. Structured Output (JSON-mode): модель должна возвращать данные в формате JSON, YAML или ином, пригодном для автоматической обработки. Это позволяет интегрировать ответы в бизнес-системы и API.
Такой подход позволяет не просто улучшить RAG, а выстроить по-настоящему надёжную систему для сложных запросов. Но он требует глубокого понимания как предметной области, так и внутренних механизмов LLM.
Эффективное использование LLM в бизнесе
При масштабировании AI-решений экономические и технические аспекты выходят на первый план. Например, при ежедневной нагрузке в 240 тысяч запросов локальное решение оказывается выгоднее облачного API. Это подтверждает кейс аналитического SAST-агента на Qwen-32B-coder: локальное решение стоит $1268 в месяц (при покупке оборудования и сроке окупаемости 16 месяцев), тогда как облачное — $1390 в месяц.
Также важно учитывать безопасность и контроль над данными. On-premise-решения обеспечивают полный контроль, что критично для финансовых организаций и девелоперов. Отсутствие передачи информации третьим сторонам снижает риски утечек и соответствует требованиям 152-ФЗ. В дополнение возможна интеграция технологий Confidential Computing для компаний с повышенными требованиями к защите данных.
От простых Naive RAG-систем к «агентным» workflow-решениям
На примере платформы ФСК мы создали мультиагентную систему, включающую:
Router-компонент для анализа входящих запросов и определения домена знаний, в котором должна быть найдена нужная информация.
Workflow-агент по разметке документов для выбора оптимальных методов обработки документов, исходя из их формата и содержания.
Workflow-агент по извлечению данных для работы с различными типами источников информации — от PDF до изображений.
Поисковые агенты с комбинированным подходом длявекторного поиска (ANN) и быстрого извлечения похожих документов и полнотекстового поиска (FTS) для повышения точности результатов.
Выбор технических компонентов
Ключ к стабильности системы — правильная конфигурация.
Для базового пайплайна мы используем модели среднего размера (7B параметров), для генерации финального ответа — более мощные (32B). Применение FP16 обеспечивает баланс между производительностью и точностью.
Для задач в финансах подбираем эмбеддинги bge-m3, для HR и Q&A — multilingual-e5-large, для русского языка — ru-en-RoSBERTa. Модель выбирается с учётом специфики данных и бизнес-контекста.
В качестве векторных хранилищ используем Milvus или Qdrant — они обеспечивают скорость и структурированность при работе с данными. При этом важно продумать иерархию: структура базы должна учитывать разметку на уровне документов и страниц.
Векторные хранилища применяем для эффективного хранения и быстрого извлечения данных в продакшене.
Для инференса чаще всего используем vLLM или SGLang, а для структурированного вывода без ошибок форматирования — xgrammar. Эти фреймворки дают нужную стабильность и предсказуемость в проде.
Систему обязательно нужно тестировать в автоматическом режиме. Мы используем подход LLM as a judge — это помогает оперативно находить слабые места и корректировать систему, повышая качество ответов. Так, благодаря внедрению мультиагентных решений в ФСК нам удалось сократить нагрузку на коммерческий департамент и службу поддержки клиентов на 30–40%.
Переход от стандартного RAG к мултиагентным workflow-системам не только улучшает качество ответов, но и значительно снижает операционные расходы при масштабировании. Решающим становится точный подбор компонентов и понимание роли каждого агента в общей архитектуре.
Когда RAG внутри агентской системы становится эффективным: реалистичные бизнес-применения
Переход от простых RAG-систем к целевым агентным решениям открывает принципиально новые возможности для бизнеса. Почему это важно — и в чём реальные преимущества?
Универсальные чат-боты на первый взгляд кажутся удобным решением: один инструмент решает любые задачи. Но на практике такие проекты сталкиваются с рядом проблем. Разработка часто превращается в бесконечный процесс без чётких критериев завершения: требования всё время растут (например, «пусть бот знает дату рождения директора» или «не выдумывает финансовые данные»), а измеримых результатов нет.
Из-за отсутствия внятных метрик сложно заранее оценить экономический эффект. ROI размывается, а поддержка системы требует серьёзных ресурсов: от 6 до 12 месяцев разработки и постоянное обновление базы знаний.
В отличие от универсальных решений, целевые AI-агенты работают иначе. У каждого — чёткая зона ответственности и бизнес-задача. Их проще интегрировать в процессы, результат можно измерить заранее, а проект имеет конкретные сроки завершения.
Измеримые бизнес-результаты от внедрения целевых workflow-агентов
Практический опыт показывает, что внедрение целевых AI-агентов позволяет добиться:
Снижения нагрузки на подразделения на 30–40%
Сокращения времени обработки запросов в 5–10 раз
Возможности заранее рассчитать окупаемость проекта благодаря чётким метрикам успеха
Сроки разработки и внедрения составляют всего один-два месяца против 6–12 месяцев для универсальных систем |
Как агентные системы работают в реальном бизнесе
В red_mad_robot мы внедряем AI-агентов в реальные процессы, где они приносят ощутимую пользу — сокращают издержки, снимают нагрузку, экономят время.
В коммерческом девелопменте workflow-агент-исследователь автоматизирует анализ рынка: собирает данные о конкурентах, ценах, темпах продаж, спросе. Раньше это делалось вручную — теперь агент подаёт сводку за минуты.
В разработке — workflow-агент для SAST находит и патчит уязвимости в коде, интегрируется в CI/CD и не требует ожидания ревью — просто вносит исправления в pull request.
В продажах — workflow-агент по генерации лидов анализирует бизнес-реестры, находит потенциальных клиентов, обогащает их контактами и отправляет в CRM. Воронка заполняется не за счёт спама, а благодаря точным, релевантным данным.
Workflow-агент — это не просто автоматизация. Он не ускоряет старый процесс, а переопределяет его. Это важно: бизнес начинает работать по-другому — с меньшими затратами, большей управляемостью и большей скоростью.
Одно успешное внедрение запускает цепную реакцию: появляется доверие к архитектуре, бизнес начинает запрашивать агентов для HR, аналитики, юридической проверки. То, что раньше казалось «ручной рутиной навсегда», масштабируется.
Ключевые факторы успеха внедрения агентных систем
Чтобы внедрение было успешным, важно учитывать несколько факторов:
Конкретная бизнес-боль: решение должно быть направлено на чётко сформулированную проблему с понятным экономическим эффектом.
Интеграционные возможности: агент должен легко и органично встраиваться в существующие бизнес-процессы и IT-ландшафт компании.
Масштабируемость: успешное решение должно быть легко масштабируемым на другие подразделения и регионы.
Измеримость результатов: с самого начала проекта должны быть установлены чёткие KPI для оценки эффективности.
Принципиальные преимущества целевых агентных систем перед универсальными чат-ботами
Вместо того чтобы инвестировать в создание одного универсального чат-бота, эффективнее строить экосистему специализированных агентов, каждый из которых является экспертом в своей области. Такой подход обеспечивает быструю отдачу от вложений, делает результаты наглядными, позволяет точно прогнозировать дальнейшие бизнес-эффекты.
Целевая архитектура не только решает отдельные задачи, но и становится фундаментом для полноценной цифровой трансформации компании.
Почему мы не делаем универсальных чат-ботов
К нам часто приходят запросы на «одного умного чат-бота, который закроет всё». Но универсальные решения почти всегда превращаются в долгострой: девять месяцев разработки, ожидания уровня Jarvis, а результат — как у Clippy.
Мы не утверждаем, что это невозможно. Но если цель — измеримый эффект за разумный срок, целевые агенты выигрывают по всем параметрам: они точнее, быстрее внедряются, дешевле в поддержке и начинают давать результат уже через один-два месяца.
Поэтому вместо одного универсального бота мы строим экосистему специализированных агентов. У каждого — чёткая зона ответственности и понятная бизнес-польза.
Итоги: что нужно, чтобы агентная система заработала
Мы не верим в универсальные рецепты, но есть практики, которые стабильно работают. Ниже — принципы, которыми мы руководствуемся при запуске агентных решений. Их применение значительно повышает шансы на успешное внедрение и достижение ожидаемых результатов.
Сначала — данные
Качество входа определяет результат. Если документация не размечена, неструктурирована или неудобна для обработки, модель будет путаться. Мы всегда начинаем с подготовки базы: комбинируем подходы к чанкингу (semantic, paragraph, sliding window), применяем hierarchical retrieval и, при необходимости, используем parent document extraction, чтобы сохранить контекст.
Если в системе есть изображения, таблицы, схемы — мы подключаем мультимодальные модели (например, qwen2.5-VL-7B-Instruct) или технологии OCR, чтобы сделать весь контент доступным для обработки LLM.
Адаптация модели под язык компании
Большинство ошибок возникает не из-за слабости моделей, а из-за того, что они «не говорят» на языке конкретного бизнеса. Чтобы избежать этого, модель должна:
Выстраивать логические цепочки рассуждений (Chain of Thought)
Расширять запросы за счёт доменного знания (query expansion)
Формировать структурированные ответы в формате JSON, YAML и других
В результате мы получаем не просто текст, а полноценные ответы, которые можно сразу интегрировать в бизнес-процессы, формы или дашборды.
Технологический стек: баланс между скоростью, качеством и ценой
Мы используем двухуровневый подход: модели на 7B параметров для базовой логики и модели на 32B — для глубокого анализа и генерации. FP16 позволяет добиться оптимального баланса между скоростью и точностью. Эмбеддинги подбираем под задачу: bge-m3 для финансов, multilingual-e5-large для Q&A и HR, ru-en-RoSBERTa для работы на русском языке. Для инференса используем vLLM или SGLang, а при необходимости структурированного вывода — xgrammar.
Workflow-агент — это тоже продукт, поэтому нужно чёткое ТЗ
Как и любое цифровое решение, агентную систему нельзя запускать «по ощущениям». Без понятной цели, метрик и этапов внедрение будет либо буксовать, либо давать эффект, который никто не сможет зафиксировать.
Определите конкретную бизнес-боль: сформулируйте чёткую проблему, которую решит ваша система
Установите измеримые KPI: например, сокращение времени обработки запросов, снижение нагрузки на определенные отделы, повышение конверсии
Выделите этапы развития системы: разделите проект на последовательные фазы с конкретными результатами на каждом этапе
Определите интеграционные точки: чётко обозначьте, как система будет взаимодействовать с существующими бизнес-процессами и IT-инфраструктурой
Разрабатывая агентные решения по этим принципам, вы значительно увеличиваете шансы на успешное внедрение и получение измеримого бизнес-эффекта. Один успешный целевой проект, как правило, открывает две-три новые возможности для автоматизации и становится основой для дальнейшей цифровой трансформации компании.
Над материалом работали
текст — Валерий Ковальский
редактура — Александра Лазарева
иллюстрации — Юлия Ефимова
Это блог red_mad_robot. Мы запускаем цифровые бизнесы и помогаем компаниям внедрять AI. Здесь наша команда разработки на собственных кейсах рассказывает о том, что происходит с AI сегодня, а стратегические аналитики подсказывают, что будет завтра. Мы бы подписались.
Наш телеграм-канал (там всё другое, а ещё есть анонсы мероприятий): t.me/redmadnews
