К началу 2025 года Сбер публично объявил о промышленном развёртывании RAG-систем на базе корпоративных документов. К середине того же года аналогичные объявления сделали ВТБ и Яндекс, сигнализируя о переходе технологии на этап промышленного внедрения. По данным отраслевых исследований, применение RAG в корпоративных проектах удвоилось в 2024 году по сравнению с 2023-м, а в 2025-м рост продолжился. Ранний бенчмарк 2026 года от Onyx показал: правильно настроенная RAG-система отвечает на рабочие вопросы лучше, чем ChatGPT, Claude и Notion AI в 64–76% случаев. Цифры впечатляют, но за ними стоит конкретная архитектурная идея, которую стоит понять, прежде чем внедрять.
В нашей практике в West Star Ltd мы столкнулись с типичным запросом: «Хотим, чтобы AI отвечал на вопросы по нашим регламентам и базе знаний, но данные за периметр компании выходить не должны». Это запрос именно на RAG. Расскажем, как это работает, что даёт и где не работает.
ЧТО ТАКОЕ RAG И ПОЧЕМУ ЭТО НЕ ПРОСТО «ЗАГРУЗИТЬ ДОКУМЕНТЫ В CHATGPT»
RAG расшифровывается как Retrieval-Augmented Generation — генерация с расширенным поиском. Идея простая: когда пользователь задаёт вопрос, система сначала ищет в ваших документах наиболее релевантные фрагменты, а затем подаёт их языковой модели как контекст. Модель отвечает, опираясь только на то, что нашла система поиска — не на своё обучение, не на интернет.
Это принципиально отличается от загрузки документов в облачный чат. В облачном чате файл целиком попадает к провайдеру (OpenAI, Anthropic, Google). При RAG данные остаются у вас, а наружу уходит только небольшой фрагмент, который сейчас нужен для ответа на конкретный вопрос.
Технически цепочка выглядит так. Документы преобразуются в векторные представления — числовые отпечатки смысла каждого фрагмента. Эти векторы хранятся в специальной базе данных. При вопросе он тоже превращается в вектор, система находит ближайшие по смыслу фрагменты из базы и передаёт их языковой модели. Модель генерирует ответ на основе этих фрагментов и указывает источник — конкретный документ и раздел.
КАК ВЫГЛЯДИТ АРХИТЕКТУРА НА ПРАКТИКЕ
В типовой корпоративной RAG-системе три уровня.
Первый — загрузка и индексирование. Документы (PDF, Word, Excel, базы знаний, сайты, отчёты) поступают в пайплайн, нарезаются на фрагменты по 200–500 слов, каждый фрагмент превращается в вектор с помощью специальной модели и записывается в векторную базу вместе с метаданными: название файла, дата, отдел, уровень доступа.
Второй — поиск. Запрос пользователя обрабатывается той же моделью, векторная база возвращает топ-5 или топ-10 наиболее похожих фрагментов. Дополнительно можно применить классический ключевой поиск (BM25) и смешать результаты — это называется гибридным поиском. Он точнее при запросах с конкретными терминами, числами или именами.
Третий — генерация и вывод. Языковая модель получает вопрос плюс найденные фрагменты и формирует ответ. Хорошая система всегда указывает источник: «По данным регламента ИОТ-14, раздел 3.2». Это позволяет пользователю перепроверить информацию самостоятельно.
По части инфраструктуры всё это может работать на одном сервере с 32–64 ГБ RAM и видеокартой от 16 ГБ (или без неё — медленнее, но возможно). Qdrant — векторная база данных на языке Rust — в 2026 году обрабатывает 10 миллионов векторов на VPS за 30–50 долларов в месяц. Если база знаний компании — это несколько тысяч документов, никакого дорогостоящего железа не нужно.
КАК ДАННЫЕ ОСТАЮТСЯ ВНУТРИ КОМПАНИИ
Ключевой вопрос при внедрении RAG — где живёт языковая модель. Если используется API облачного провайдера, фрагменты документов уходят на внешние серверы при каждом запросе. Это может не соответствовать политике безопасности, требованиям регулятора или условиям клиентских договоров.
Альтернатива — локальные открытые языковые модели. В 2026 году их качество на задачах работы с корпоративными текстами вплотную приблизилось к коммерческим решениям. Такие модели разворачиваются на корпоративном сервере и не передают данные никуда. Запрос обрабатывается полностью внутри инфраструктуры компании.
Дополнительно настраивается разграничение доступа на уровне векторной базы. Контекстный контроль доступа позволяет указать: документы отдела HR видит только HR, регламенты по безопасности — только сотрудники с допуском. Система поиска при формировании ответа отфильтрует фрагменты, к которым у запрашивающего нет прав. Пользователь не получит закрытую информацию, даже если задаст прямой вопрос.
Microsoft GraphRAG, появившийся в 2024 году, предложил ещё один подход: вместо плоского векторного индекса строится граф знаний, где сущности — люди, продукты, процессы — связаны явными отношениями. Это значительно улучшает ответы на вопросы, требующие агрегации из множества источников: «Кто отвечает за процесс X» или «Как изменились правила Y с прошлого года». На практике GraphRAG полезен там, где в документах много перекрёстных ссылок; для простого поиска по регламентам стандартный векторный RAG эффективнее.
СЦЕНАРИИ, ГДЕ RAG РАБОТАЕТ
Важно понимать: RAG не универсальный ответ на все задачи с документами. Он хорошо работает там, где нужно найти и объяснить информацию из большого корпуса текстов. Ниже — четыре сценария, где технология даёт реальный эффект.
Внутренняя база знаний и регламенты. Сотрудники спрашивают «как оформить командировочные» или «каков срок ответа на претензию» и получают точный ответ со ссылкой на документ. Вместо поиска по папкам и чтения сорокастраничного регламента — один вопрос.
Техническая документация. Инженеры находят параметры оборудования, инструкции по обслуживанию, журналы неисправностей. Система работает как умный поиск. При обновлении инструкции новая версия автоматически вытесняет старую из индекса — инженер не рискует работать по устаревшей схеме.
Клиентская поддержка. Операторы задают вопрос в интерфейс, а система мгновенно находит нужный пункт договора, тарифный план или процедуру возврата. Время обработки обращения сокращается, качество ответов становится стабильнее.
Онбординг новых сотрудников. Вместо того чтобы нагружать опытного коллегу однотипными вопросами, новичок задаёт их системе напрямую. Ответы появляются мгновенно и со ссылкой на источник.
Анализ контрактов и юридических документов. Юрист задаёт вопрос по пакету договоров — система находит все упоминания конкретного условия или срока, не перечитывая каждый файл вручную.
ОГРАНИЧЕНИЯ И СЛАБЫЕ МЕСТА
Качество зависит от качества документов. RAG не исправляет противоречивые или устаревшие регламенты — он их воспроизводит. Если в базе знаний три версии одного документа, система может ответить по устаревшей. Подготовка документов к индексированию — отдельная работа, которую обычно недооценивают на этапе планирования.
Галлюцинации не исчезают полностью. Языковая модель может додумать детали, не содержащиеся в найденных фрагментах, — особенно если релевантного документа в базе нет вообще. Важно приучить пользователей проверять источник, который система указывает рядом с ответом.
Нестандартные форматы плохо парсятся. Отсканированные PDF без текстового слоя, таблицы со сложной структурой, схемы и чертежи требуют отдельных инструментов. OCR и конвертеры добавляют ошибки, которые потом появляются в ответах.
Поддержание актуальности требует процесса. RAG — не разовое внедрение. Когда регламенты обновляются, старые векторы нужно удалять и добавлять новые. Без автоматизации база знаний постепенно устаревает, и доверие к системе падает.
Медленный старт при большой базе документов. Первичное индексирование тысяч документов может занять часы. Инкрементное обновление требует продуманной реализации с самого начала.
Небольшие компании переоценивают сложность и не начинают. RAG из открытых компонентов — реалистичный проект на несколько недель. Но воспринимается как «AI-проект» с непонятным бюджетом и откладывается на потом.
КАК ОЦЕНИТЬ ГОТОВНОСТЬ КОМПАНИИ К RAG
Три вопроса, которые помогут принять решение. Первый: есть ли хотя бы 200–300 документов, которые сотрудники реально ищут — регламенты, инструкции, договоры? Второй: есть ли повторяющиеся вопросы, на поиск ответа на которые тратится более 10–15 минут? Третий: есть ли требование, чтобы данные не покидали периметр компании?
Если на все три ответ «да» — RAG даст измеримый результат уже на пилоте. Если база знаний плохо структурирована или не актуализировалась последние пару лет — сначала нужна работа с документами.
Для пилота достаточно одного отдела, одной категории документов и открытого стека: LangChain или LlamaIndex как оркестратор, Qdrant или Chroma как векторная база, Ollama для локальной языковой модели. Первый прототип — за одну-две недели при выделенном разработчике. Главное от бизнеса — чёткий список документов и один отдел, готовый давать обратную связь.
ВЫВОД ПО АУДИТОРИЯМ
Специалисту. RAG — зрелая технология с открытым стеком. Qdrant, LlamaIndex, Ollama разворачиваются локально за несколько часов. Основная сложность не в коде, а в качестве пайплайна обработки документов и настройке разграничения доступа. Уделите время стратегии разбивки на фрагменты — слишком короткие или длинные куски напрямую влияют на точность поиска. Начните с одного типа документов и итерируйте.
Руководителю. Основная метрика — время сотрудника на поиск информации. Замерьте текущее среднее, внедрите пилот на одном отделе, замерьте снова. Проект оправдывает себя при сокращении времени поиска на 30% и более. Важно обеспечить процесс обновления документов — без него система деградирует.
Собственнику. RAG даёт конкурентное преимущество там, где знания компании накоплены, но плохо доступны. Это ускоряет адаптацию новых сотрудников, снижает зависимость от носителей экспертизы, которые могут уйти, и создаёт основу для следующего шага: AI-агентов, которые не просто ищут, но действуют. При правильной архитектуре данные остаются полностью внутри компании.
ЧАСТЫЕ ВОПРОСЫ
— Нужно ли покупать дорогостоящее оборудование?
При типичной корпоративной базе знаний в несколько тысяч документов хватает сервера с 32–64 ГБ RAM. GPU желательна для скорости, но не обязательна на старте. Стоимость облачного VPS — от 30 до 150 долларов в месяц в зависимости от объёма.
— Можно ли использовать RAG с уже существующими системами учёта?
Да, но потребуется интеграционный слой. Данные экспортируются, проходят очистку и индексируются. Изменения синхронизируются по расписанию или в реальном времени. Стандартная задача, но требует отдельного планирования.
— Что лучше — облачный RAG или self-hosted?
Облачный быстрее запустить. Self-hosted даёт полный контроль над данными и ниже операционные расходы при росте объёма. Для компаний с требованиями к локализации данных — self-hosted предпочтительнее.
— Как убедиться, что система не даёт устаревший ответ?
Настройте обязательное указание источника в каждом ответе — сотрудник видит ссылку на документ и дату обновления. Дополнительно — мониторинг изменений: если файл обновился, система помечает связанные фрагменты как требующие переиндексирования.