RAG для корпоративных данных: почему без него ваш «корпоративный ChatGPT» не принесёт денег
Я наткнулся на материал о Retrieval-Augmented Generation, где автор честно написал: «LLM без доступа к вашим данным — дорогой собеседник, а не бизнес-инструмент».
Мне это очень откликнулось, потому что в БизнесМатике мы видим один и тот же сценарий: компания запускает «корпоративный ChatGPT», показывает красивое демо, а через месяц у проекта нет ни пользователей, ни понятного эффекта.
В этой статье я разберу, как на самом деле устроен RAG для корпоративных данных, почему без него LLM в бизнесе почти всегда остаётся игрушкой для демо и какие решения нужно принять C-level и IT, чтобы превратить GenAI в новый слой вашей архитектуры — с измеримыми цифрами по выручке и издержкам, а не только с презентациями.
Корпоративный ChatGPT, который никому не нужен
Сценарий, который я слышу от CIO и Head of Data последние полтора года, почти всегда одинаковый.
«Нас попросили сделать корпоративного ChatGPT. Мы развернули модель, прикрутили интерфейс, загрузили туда пару внутренних документов. Все порадовались на демо. Через пару недель никто не пользуется. Что мы сделали не так?».
Если посмотреть глубже, такие проекты вообще не про доступ к корпоративному знанию.
Модель отлично пишет по-человечески, но не знает, как у вас реально устроены скидки, SLA по доставке, бонусы персоналу и оформление возвратов для ключевых клиентов. В лучшем случае ей скармливают несколько PDF из портала. В худшем — она отвечает «как в интернете» по общим best practices, которые мало связаны с вашей реальностью.
Сотрудники это чувствуют очень быстро:
- на общие вопросы она отвечает красиво, но «ни о чём»;
- на конкретные — начинает фантазировать или цитировать устаревшие регламенты;
- по сложным темам всё равно приходится звонить коллеге, который «точно знает, как у нас принято».
- в отчётах остаётся единственный KPI — количество диалогов;
- ни CFO, ни операционный директор не видят эффекта в деньгах или FTE;
- после первых громких «галлюцинаций» по юридическим или комплаенс-темам доверие к проекту падает ниже нуля.
Проблема здесь не в LLM как таковой. Проблема в том, что мы не дали ей нормального доступа к корпоративному знанию — данным из CRM, ERP, DMS, тикет-систем, базам знаний и реальной истории кейсов. И вот на этом месте в игру входит RAG.
Что такое RAG простыми словами и зачем он бизнесу?
Retrieval-Augmented Generation звучит как термин из исследовательской статьи, но идея очень приземлённая.
Представьте нового сотрудника, который блестяще пишет и объясняет сложные вещи, но не знает вашей компании. Вы даёте ему доступ к базе знаний, CRM, договорам, внутренним политикам и чатам экспертов. Через пару недель он перестаёт фантазировать и начинает отвечать «как у нас принято», опираясь на реальные документы.
Каждый раз, когда пользователь задаёт вопрос, система сначала идёт не в «абстрактное мировое знание модели», а в индексы ваших внутренних данных: вытаскивает оттуда релевантные фрагменты документов, тикетов, регламентов. Уже на этот контекст опирается модель, когда формулирует ответ.
На уровне бизнеса это воздействует на вполне конкретные показатели:
- В поддержке — сокращается время поиска ответа и доля эскалаций, растёт FCR и доля самообслуживания.
- В юр- и комплаенс-функции — ускоряется поиск по договорам и политикам, меньше повторяющихся «типовых» запросов к старшим юристам.
- В бэк-офисе — снижается время онбординга: новым сотрудникам не нужно помнить весь регламент, достаточно уметь задавать правильные вопросы ассистенту.
Нужно честно проговорить ограничение: RAG не исправит мусор в исходных данных.
Если у вас три противоречивые версии процесса, устаревшие регламенты и неопределённые источники «истины», ассистент аккуратно отразит этот хаос. Это не баг, а зеркало вашей архитектуры данных и процессов.
Архитектура RAG под капотом для корпоративных данных
На слайдах RAG часто выглядит как маленький блок «поиск по документам» рядом с LLM. В реальной корпорации это отдельный слой архитектуры. Давайте разберём его по частям.
Первый вопрос не про модели, а про то, где у вас живёт знание:
- CRM и тикет-системы — обращения клиентов, макросы и шаблоны ответов, кейсы по нестандартным ситуациям.
- ERP и отраслевые системы — статусы заказов, ценовые условия, схемы поставок.
- DMS/ECM, сетевые папки — договоры, политики, регламенты, инструкции, протоколы.
- Порталы, Confluence, SharePoint — статьи базы знаний, Q&A, внутренние FAQ.
- Почта и мессенджеры (там, где это допустимо) — ответы экспертов, которые так и не попали в формализованную базу.
RAG-проект начинается с инвентаризации и приоритизации этих источников. Если этого не сделать, модель будет «есть» случайные документы и воспроизводить случайную картину мира.
Пайплайн подготовки: ETL и нарезка на фрагменты
Дальше нужен аккуратный пайплайн:
- коннекторы к системам (вплоть до выкачки через API и лог-шины);
- парсинг документов в нормальный текст (PDF, DOCX, HTML, почтовые треды);
- очистка: удаление мусора, оглавлений, дублей;
- нарезка на фрагменты — chunks объёмом от нескольких сотен до тысячи токенов.
К каждому фрагменту добавляются метаданные:
- тип документа (договор, инструкция, тикет);
- права доступа (роль, подразделение, уровень).
Именно эти метаданные потом позволяют:
а) не показывать сотруднику то, что он не должен видеть;
б) отдавать приоритет свежим и утверждённым версиям документов.
Следующий слой — векторные представления.
Каждый фрагмент прогоняется через модель эмбеддингов (как правило, отдельную от LLM), которая переводит текст в вектор. Фрагменты с близким смыслом оказываются рядом, даже если формулировки разные.
В реальных системах редко ограничиваются одним индексом. Логично делать несколько:
- по доменам («поддержка», «юристы», «HR»);
- по уровням конфиденциальности.
Это позволяет на этапе поиска сузить пространство и не смешивать, например, юридические документы с разрозненными письмами из почты.
Когда пользователь задаёт вопрос, происходит цепочка действий:
1. Вопрос преобразуется в вектор.
2. Система ищет ближайшие фрагменты в одном или нескольких индексах (approximate nearest neighbors).
3. Отфильтровывает результаты по правам доступа и другим бизнес-правилам.
4. При необходимости переранжирует найденное, используя более «тяжёлую» модель, которая оценивает, насколько фрагмент действительно отвечает на вопрос.
- отличать устаревший регламент от актуального;
- учитывать важные поля метаданных (тип документа, утверждённость);
- возвращать не один, а набор фрагментов, достаточный для уверенного ответа.
Здесь же появляется то, о чём редко говорят на демо: нужны метрики качества retrieval — хотя бы простые precision@k, доля успешных ответов по ключевым сценариям, список запросов, на которые система не смогла ответить.
Всё найденное складывается в prompt вместе с вопросом и инструкциями:
- как отвечать (формат, тон, язык);
- что важно учитывать (правовые риски, политика по скидкам, ограничения по обещаниям клиенту);
- что делать, если контекста недостаточно («признайся, что не нашёл ответа»).
- feedback-loop от пользователей;
- A/B-тесты разных стратегий retrieval и разных моделей.
Два наиболее болезненных места:
- Обновление индекса. Если данные в индекс попали один раз и навсегда, через месяц ассистент начинает советовать старые версии документов и «утверждённые» процедуры, которые уже переписали. Нужен понятный цикл обновления и процесс снятия с публикации.
- Governance. Кто отвечает за качество ответов в юридических сценариях? Как вы реагируете на ошибочные ответы? Кто владеет данными, на которые опирается ассистент? Без ответов на эти вопросы RAG будет жить на ответственности одного энтузиаста из IT.
Где RAG даёт деньги: живые кейсы вместо гипотез
Теперь самое важное — где это всё превращается в деньги и FTE.
Ассистент поддержки в DIY-ретейле
В одном из проектов в DIY-сети мы делали ассистента для клиентской поддержки.
51 магазин, десятки тысяч SKU, клиентские обращения 24/7 — от статуса заказа до сложных вопросов по доставке, возвратам и гарантиям.
Под капотом это был классический RAG:
- коннекторы к CRM и базе знаний;
- векторный индекс по историческим обращениям и регламентам;
- retrieval релевантных кейсов и инструкций;
- LLM, которая из этого конструировала ответ понятным языком.
- до 35% обращений уходят в самообслуживание через ассистента без участия оператора;
- дежурная смена поддержки сократилась до 4 человек на 24/7, при этом качество ответа не просело;
- клиенты начали чаще пользоваться ассистентом именно потому, что он отвечал «как по регламенту компании», а не абстрактными фразами.
Это не косвенные эффекты вроде «инновационный имидж», а вполне осязаемые снижение нагрузки и экономия на FTE.
Те же принципы работают для внутреннего ассистента:
- сотрудники задают вопросы по HR-политикам, IT-процессам, операционным регламентам;
- ассистент поднимает из индекса актуальные статьи базы знаний, регламенты, Q&A;
- модель формулирует ответ, а при необходимости — даёт ссылки на исходные документы.
Главный эффект — снижение количества «мелких» вопросов к линейным руководителям и экспертам:
они перестают быть «ходячей базой знаний», а фокусируются на принятии решений, а не на раздаче ссылок.
Для юристов и комплаенс-офицеров RAG-слой позволяет:
- искать нужные договоры и политики по смыслу, а не по названию файла;
- быстро собирать подборки релевантных кейсов под конкретный вопрос;
- уменьшать количество повторяющихся «типовых» запросов к старшим коллегам.
Важный момент: здесь RAG не должен принимать решения.
Он экономит часы на поиске и первичном анализе, но финальное слово остаётся за человеком, и это нужно явно зафиксировать в регламенте использования.
Почему 9 из 10 LLM-пилотов умирают без RAG
Если обобщить провальные истории, они почти всегда про одно и то же:
компания запускает не продукт, а демо.
- сделали «бота на LLM», показали демо на внутренних документах;
- не разобрались с источниками правды, качеством данных, governance;
- не договорились, какие процессы и метрики он должен менять.
- пользователи не понимают, когда ассистенту можно доверять, а когда нет;
- бизнес не видит, что меняется в SLA, FTE или выручке;
- IT остаётся «виноватым», хотя проблема в том, что проект вообще не был про архитектуру данных.
RAG-подход вынуждает задать неприятные вопросы:
- Какие 1–2 процесса мы хотим улучшить в первую очередь?
- Где живут данные, которые описывают эти процессы, и в каком они состоянии?
- Кто отвечает за эти данные и готов участвовать в проекте?
- Как мы будем измерять качество retrieval и ответы по ключевым сценариям?
Если таких ответов нет, даже очень хорошая модель не спасёт.
Без RAG и без работы с данными LLM в бизнесе будет оставаться игрушкой — красивой, но бесполезной.
Шаги для C-level и IT: от хайпа к новой архитектуре
Для C-level разговор про RAG — это не про модели и вендоров. Это про архитектуру и управляемый риск.
- Сформулируйте 1–2 приоритетных сценария: поддержка клиентов, юридические запросы, внутренний поиск.
- Привяжите их к цифрам: время обработки, доля самообслуживания, экономика FTE, NPS, скорость онбординга.
- Определите «красные зоны», где ошибки ассистента недопустимы, и зоны, где возможен более свободный эксперимент.
Для CIO, Head of IT, Head of Data
- Сделайте инвентаризацию источников знаний: системы, форматы, владельцы.
- Оцените техническую готовность: есть ли API, шина данных, DWH, где можно строить поверх RAG-слой.
- Определите архитектурные решения: on-prem или облако, open source или конкретный вендор, как это стыкуется с существующей IT-стратегией.
- Назначьте владельца RAG-продукта и договоритесь, как будет выглядеть выпущенная в прод версия, а не вечный пилот.
Без этого RAG-проект обречён жить в статусе «демо у энтузиаста».
С этим — он имеет шанс стать тем самым слоем доступа к корпоративному знанию, которым ежедневно пользуются сотни сотрудников.
Нативный следующий шаг: ИИ-аудит готовности к RAG и GenAI
Перед тем как выбирать стеки, подписывать контракты с вендорами и рисовать архитектурные схемы, полезно честно измерить, где вы находитесь. Не в смысле «мы верим в ИИ», а в смысле готовности к RAG и GenAI по конкретным измерениям.
Формат, который мы хорошо обкатали, — короткий ИИ-аудит готовности:
- за неделю мы смотрим на шесть измерений: стратегию, данные, технологии, людей, процессы и governance;
- фиксируем, какие данные реально доступны для RAG и в каком они состоянии;
- оцениваем риски по безопасности и качеству;
- собираем карту потенциальных RAG-кейсов и прикидываем для них эффект (экономия FTE, ускорение процессов, влияние на выручку).
На выходе у вас не «ещё одна презентация про ИИ», а профиль зрелости, матрица приоритизации и понятный роадмап: с чего начать, какие 1–2 сценария запустить первыми и какие изменения в данных и архитектуре нужны, чтобы эти пилоты не умерли.
Если вы в этой статье узнали свои «мертвые» LLM-боты, которые красивы на демо и бесполезны в проде, возможно, следующий шаг для вас не «ещё один пилот», а именно такой аудит.
А если хочется глубже разбираться в архитектурах RAG, кейсах и ограничениях GenAI в реальном бизнесе — у нас есть Telegram-канал, где мы честно разбираем такие истории и без розовых очков, и без апокалипсиса.