RAG-система для компании

Введение

В большинстве компаний есть папка с регламентами, договорами и инструкциями, а ещё переписка, где за годы накопились ответы на типовые вопросы. Новый сотрудник тратит недели, чтобы понять, как устроен возврат, какой срок согласования у закупки или где лежит актуальная версия прайса. Опытные коллеги отвечают по памяти, и каждый такой вопрос отвлекает их от основной работы.

Большие языковые модели умеют отвечать на вопросы и составлять тексты, но сами по себе не знают ваших внутренних документов. Если спросить модель о вашем регламенте без доступа к нему, она ответит правдоподобно, но без опоры на источник. Эту проблему решает RAG (retrieval-augmented generation), то есть генерация ответа с предварительным поиском по документам.

В этом материале разберём, как устроена RAG-система для компании, какие процессы она закрывает, что нужно для запуска и где она ошибается. Это не волшебная кнопка: качество зависит от документов, прав доступа и того, как вы проверяете ответы. Если вы только выбираете подход, начать можно с базы знаний W1DO об ИИ, RAG и автоматизации.

Что изменилось: поиск стал частью ответа

Раньше поиск по документам означал полнотекстовый поиск по словам. Сотрудник вводил «возврат», получал список файлов и сам читал их. Сейчас система может сначала найти нужные фрагменты, а потом передать их модели вместе с вопросом. Модель отвечает, опираясь на найденный текст, и может показать, из какого документа взят ответ.

Главное здесь не сама модель, а поиск перед ней. Качество ответа определяется тем, попал ли нужный фрагмент в контекст. Поэтому развитие RAG идёт в основном в сторону поиска: лучшего разбиения документов, гибридного поиска по смыслу и по словам, переранжирования результатов.

В сентябре 2024 года Anthropic опубликовала результаты экспериментов с contextual retrieval. По их измерениям на тестовых наборах, добавление контекста к каждому фрагменту документа снизило долю случаев, когда нужный фрагмент не попадал в топ-20 результатов, на 35%. Сочетание контекстных эмбеддингов и контекстного BM25 дало снижение на 49%, а добавление переранжирования, на 67%. Эти цифры получены на данных Anthropic, поэтому на ваших документах результат будет другим. Но направление понятно: поиск нужно настраивать и измерять так же тщательно, как выбор модели.

Для тех, кто следит за рынком агентов, полезен обзор новостей про ИИ-агентов за октябрь 2026. Там видно, как агенты всё чаще работают с внутренними данными через поиск и инструменты.

Как работает RAG простыми словами

Схема состоит из двух частей: загрузка документов и ответ на вопрос.

При загрузке документы разбивают на фрагменты (чанки). Обычно это абзацы или разделы длиной от нескольких сотен до нескольких тысяч знаков. Для каждого фрагмента считают эмбеддинг, числовое представление смысла текста, и сохраняют его в векторной базе. Рядом часто держат обычный поисковый индекс по словам, потому что точные термины вроде номера договора или артикула векторный поиск находит хуже.

Когда сотрудник задаёт вопрос, система превращает его в эмбеддинг и ищет ближайшие фрагменты. Затем результаты при необходимости переранжируют, то есть заново упорядочивают по релевантности. Лучшие фрагменты передают модели вместе с инструкцией: отвечать только по ним и честно писать, если ответа в документах нет. Готовый ответ возвращается со ссылками на источники.

Векторной базой может быть отдельная СУБД, например Qdrant или Weaviate, либо расширение pgvector для PostgreSQL, если компания уже работает с этой базой. Для небольшого и среднего объёма документов обычно хватает одного сервера. Выбор зависит от объёма, требований к скорости ответа и от того, где должны храниться данные.

Какую проблему бизнеса решает

Основная проблема в том, что знание существует, но недоступно в нужный момент. Оно распределено по файлам, почте, мессенджерам и памяти сотрудников. Отсюда три типичные потери: время сотрудников уходит на поиск ответа, клиенты получают разные ответы от разных людей, а новички входят в работу дольше, чем могли бы.

RAG не заменяет эксперта в спорных вопросах, но снимает рутину. Вопрос «можно ли вернуть товар после вскрытия упаковки» не должен требовать звонка руководителю, если ответ записан в регламенте. Вопрос о налоговом режиме конкретной услуги устроен иначе: ответ должен опираться на актуальный документ и проверяться специалистом.

Важно сразу обозначить границу. RAG отвечает по тому, что ему дали. Если регламент устарел, ответ будет устаревшим, но звучать уверенно. Поэтому внедрение начинается не с выбора модели, а с инвентаризации документов: какие из них актуальны, кто их владелец и когда их последний раз обновляли.

Какие процессы можно автоматизировать

Чаще всего RAG-система окупается там, где вопросы повторяются, а ответ уже записан:

• ответы сотрудников первой линии поддержки на вопросы о тарифах, доставке, возвратах и гарантии;
• внутренний помощник для новых сотрудников: адаптация, отпуск, согласования, доступы к системам;
• поиск по договорам и приложениям: сроки оплаты, штрафы, условия пролонгации, с обязательной проверкой юристом;
• ответы менеджеров по продукту: характеристики, комплектация, совместимость;
• черновики ответов клиентам на основе базы знаний, которые человек проверяет перед отправкой;
• поиск по инструкциям и сервисным регламентам для инженеров;
• поиск расхождений между версиями документов, например старого и нового прайса.

Каждый процесс стоит отбирать по простому критерию: есть ли повторяющиеся вопросы, есть ли ответ в документах и кто проверит результат. Если на один из этих вопросов ответа нет, автоматизировать пока рано.

Сценарии для разных компаний

Интернет-магазин. База содержит карточки товаров, правила возврата, условия доставки и гарантии. Поддержка получает подсказку с источником и быстрее отвечает на типовые обращения. Ориентировочно это снимает нагрузку с первой линии, но точный эффект нужно измерить на ваших обращениях.

Производственная компания. В базе технические паспорта, инструкции по эксплуатации, сервисные регламенты. Инженер на объекте спрашивает про конкретную модель оборудования и получает нужную процедуру без поиска по сотням файлов.

Юридическая или финансовая служба небольшой компании. Поиск по шаблонам договоров и внутренним политикам. Ответ в этом случае служит подсказкой, решение принимает юрист или бухгалтер, а источник всегда доступен для проверки.

Агентство или студия услуг. База кейсов, прайсов и коммерческих условий. Менеджеры быстрее готовят коммерческие предложения и не путают версии условий.

Компания с филиалами. Единая база с правилами, которые различаются по регионам. Здесь важна фильтрация по региону при поиске, иначе сотрудник получит правило из соседнего филиала.

Во всех сценариях решающий фактор один: кто отвечает за актуальность документов. Без этого даже хорошо настроенная система начинает уверенно повторять устаревшие правила.

Пошаговый план внедрения

1. Выберите один процесс и одну группу пользователей, например первую линию поддержки и двадцать самых частых вопросов.
2. Соберите 50–100 реальных вопросов из переписки и запишите к каждому эталонный ответ с указанием источника. Это тестовый набор, без него невозможно понять качество системы.
3. Проведите инвентаризацию документов: актуальность, владелец, формат. PDF-сканы нужно распознать, а таблицы и схемы разбираются сложнее текста, и это стоит заранее учесть.
4. Настройте загрузку и разбиение документов, индекс и права доступа по ролям.
5. Подключите модель и инструкцию: отвечать только по источникам, отказываться, если ответа нет, показывать ссылки на фрагменты.
6. Прогоните тестовый набор и измерьте долю верных ответов и долю ответов без источника. Ошибки поиска и ошибки генерации разбирайте отдельно, потому что лечатся они по-разному.
7. Запустите пилот на ограниченной группе. Несколько недель каждый ответ должен проверять человек.
8. Расширяйте базу: новые документы, новые процессы, интеграция с CRM или тикет-системой.

Если нужна команда, которая соберёт такой пилот и сопроводит запуск, посмотрите услуги по внедрению ИИ в бизнес-процессы W1DO. Сроки пилота зависят от качества документов и скорости согласования доступов. Ориентировочно это несколько недель на подготовку и тестирование плюс период наблюдения.

Требования к данным и инфраструктуре

Данные. Нужны электронные документы с текстовым слоем, а не только сканы. У каждого документа должны быть дата редакции, владелец и статус «актуален» или «архив». Эти поля помогают не выдавать старые регламенты за действующие.

Доступы. Учётные записи сотрудников и роли должны быть связаны с поиском. Система не должна показывать фрагменты, которые пользователю видеть нельзя. Это проверка на уровне поиска, а не только интерфейса: иначе ответ может содержать текст, которого пользователь не видит на экране, но получил через модель.

Инфраструктура. Нужны сервер или облачная среда для индекса и выбор модели. Облачная модель через API проще в запуске. Локальная модель оставляет данные внутри периметра, но требует видеокарты или достаточного объёма оперативной памяти, и это зависит от выбранной модели. Подробнее о локальных агентах написано в материале о локальных ИИ-агентах.

Интеграции. Источники документов: файловое хранилище, вики, 1С, CRM. Логирование запросов и ответов нужно для разбора ошибок и для контроля.

Команда. Минимум три роли: владелец знаний, который отвечает за документы; разработчик, который настраивает систему; эксперт, который проверяет ответы на пилоте. Если архитектуру проектирует внешний подрядчик, он должен работать с этими людьми, а не только с техническим заданием. Для проектирования таких систем у W1DO есть отдельная услуга по проектированию и разработке AI-систем.

Экономический эффект

Эффект лучше оценивать по времени, а не по обещаниям. Формула простая: сколько раз в неделю задают вопрос, сколько минут сотрудник тратит на поиск ответа и какая часть вопросов закрывается без участия человека. Например, если 300 вопросов в неделю по 5 минут каждый, это 25 часов работы. Если система закрывает треть таких вопросов, экономия составит около 8 часов в неделю. Это оценочный показатель, его нужно проверить на данных компании.

Расходы складываются из разработки и настройки, хостинга, использования модели (платного API или собственной инфраструктуры), поддержки базы знаний и времени экспертов на проверку. Суммы зависят от объёма документов, числа пользователей и выбранной модели, поэтому здесь цифр нет. Для планирования стоит попросить подрядчика сделать расчёт под ваш объём.

Кроме времени, есть эффекты, которые сложнее измерить: единообразие ответов клиентам и сокращение срока адаптации новых сотрудников. Их стоит зафиксировать до запуска, иначе после пилота сравнивать будет не с чем.

Риски и ограничения

• Устаревшие документы. Система уверенно цитирует старый регламент. Защита: владелец документа и дата последнего обновления в метаданных.
• Пропущенный фрагмент. Если поиск не нашёл нужный раздел, модель может ответить неверно. Поиск нужно тестировать отдельно от модели.
• Противоречивые документы. Два регламента с разными сроками. Система сама не решает, какой правильный, поэтому должна показывать оба источника.
• Ответы без опоры на источник. Если инструкция нечёткая, модель дополняет ответ собственными знаниями. Ограничивайте ответы документами и требуйте ссылки.
• Неформальные правила. RAG не знает того, что никто не записал: договорённостей в переписке, устных исключений, привычек отдела.
• Юридическая ответственность. Ответы о договорах, налогах и гарантиях не заменяют заключения специалиста.

Безопасность и защита данных

Документы компании часто содержат персональные данные клиентов и сотрудников, а также коммерческую тайну. Для России важны требования закона о персональных данных (152-ФЗ). Прежде чем загружать документы, определите, какие данные попадут в индекс и где они будут храниться. Если модель облачная, проверьте, куда уходят запросы и фрагменты документов и какие условия обработки предлагает провайдер. Вопросы соответствия лучше согласовать с юристом.

Права доступа должны действовать при поиске, то есть пользователь получает только те фрагменты, которые ему положены. Логи запросов полезны для разбора ошибок, но сами содержат данные, поэтому их срок хранения тоже нужно задать. Не загружайте в индекс пароли, ключи API и реквизиты доступа. Это нужно проверять до загрузки, потому что после попадания в индекс такие данные трудно удалить полностью.

Если документы особенно чувствительны, рассмотрите локальную модель и векторную базу внутри периметра компании. Это увеличивает расходы на инфраструктуру, но снижает риск передачи данных наружу. Решение принимает владелец данных вместе с юристом и службой безопасности.

Сравнение с альтернативами

Полнотекстовый поиск по файлам. Дешёвый и предсказуемый, но возвращает документы, а не ответы. Подходит, если пользователи готовы сами читать.

Дообучение модели (fine-tuning). Меняет поведение модели, но плохо подходит для документов, которые часто меняются, и требует подготовленных данных и бюджета. Для фактов из регламентов RAG обычно проще и быстрее обновляется.

Загрузка файлов в чат-сервис. Быстро для одного человека, но трудно контролировать доступ и хранение. Для команды нужна отдельная система.

Передача всех документов в запрос. Работает на небольшом объёме, но дорого и медленно, и не решает вопрос прав доступа.

Готовые корпоративные платформы. Сокращают разработку, но обычно дороже по лицензиям и менее гибки. Сравнивайте их по тому, как они решают права доступа и обновление данных, а не по презентации.

Вывод и следующий шаг

RAG даёт компании ответы по её собственным документам с опорой на источники и без переобучения модели. Результат зависит не столько от модели, сколько от трёх вещей: актуальности документов, качества поиска и тестового набора вопросов, по которому вы проверяете систему.

Начните с одного процесса и одной группы сотрудников. Соберите 50–100 вопросов, инвентаризуйте документы и через несколько недель сравните цифры до и после. Если нужна команда, которая соберёт пилот и сопроводит запуск, посмотрите кейсы W1DO: там описаны проекты по автоматизации. Если в работе уже есть учётная система, полезен и пример MCP-сервера для 1С, который показывает, как агент подключается к данным бухгалтерии.