RAG для компании: от поиска по документам до полезного ассистента

Представь нового сотрудника поддержки. Клиент спрашивает, можно ли вернуть оборудование после обновления прошивки. В wiki есть инструкция, в PDF — исключение для старой модели, а в чате — сообщение, что правило вчера изменилось. Сотрудник умеет читать. Проблема в том, что сначала надо найти правильное, действующее и доступное именно ему правило.

С языковой моделью происходит похожая история. Она умеет объяснять, сопоставлять и формулировать. Но откуда ей знать, что твоя компания вчера поменяла условия? Надпись «самая умная нейросеть» доступ к внутренней wiki не выдаёт.

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

Что такое RAG — без словаря на полстраницы

Retrieval-Augmented Generation — генерация ответа с использованием найденной информации. Сначала система ищет материалы, относящиеся к вопросу. Затем передаёт выбранные фрагменты модели вместе с вопросом. Модель составляет ответ, опираясь на этот контекст.

Это похоже на экзамен с открытой книгой. Только библиотекарь должен принести нужную книгу, открыть правильную страницу и проверить, что перед ним действующее издание. Если он принёс инструкцию от соседнего продукта, красноречие экзаменуемого не спасёт.

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

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

Что происходит внутри

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

Когда меняются документы

01ИсточникиИнструкции, файлы, wiki

02ПодготовкаТекст, разделы, версия, права

03ИндексСлова + смысловые векторы

Когда приходит вопрос

01Запрос и доступЧто нужно и что разрешено

02Поиск и отборАктуальные фрагменты с источниками

03Ответ моделиВывод, ссылки или честный отказ

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

Ответ на вопрос происходит во время работы пользователя. Система определяет доступные ему источники, ищет кандидатов, отбирает релевантные фрагменты и передаёт их модели. После генерации проверяет формат ответа, существование ссылок и соответствие каждого существенного вывода найденному фрагменту. Одна рабочая ссылка не доказывает, что источник подтверждает ответ; для критичных выводов нужна отдельная проверка. Если достаточного основания нет, полезным ответом может быть уточнение или отказ делать вывод.

Индекс — вспомогательное представление документов для поиска. Он не должен становиться второй бесхозной версией корпоративной правды. Нужно понимать, откуда взялся каждый фрагмент и когда он обновлён.

Чанки: почему нельзя просто нарезать текст по линейке

Чанк — фрагмент, который поисковая система может найти и передать в ответ. Слишком короткий теряет контекст, слишком длинный тянет лишний материал. Размер выбирают экспериментом на своих вопросах, а не как счастливое число из туториала.

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

Допустим, один абзац говорит «возврат возможен в течение 30 дней», а следующий — «для активированных устройств действует отдельная процедура». Если второй абзац потерялся, поиск может быть формально успешным, а ответ — опасно неполным.

Эмбеддинги: поиск похожего смысла

Эмбеддинг — числовое представление текста. Модель эмбеддингов преобразует вопрос и фрагменты в векторы, а поиск находит близкие представления. Поэтому «как восстановить доступ» может привести к инструкции «сброс пароля», даже если слова не совпадают.

Но сходство не равно истинности. Старая и новая инструкции могут быть почти одинаковыми. Номер договора, артикул и код ошибки часто требуют точного совпадения. Поэтому гибридный поиск сочетает слова и смысл: например, BM25 с векторным поиском.

После поиска можно применить reranker — модель, которая подробнее сравнит вопрос с каждым кандидатом и изменит порядок. Это дополнительный этап с собственной задержкой и стоимостью. Если он не улучшает ответы на контрольном наборе, держать его ради солидного названия незачем.

В моём RAG-ассистенте результаты BM25 и семантического поиска объединяются через RRF. Метод учитывает позиции в разных списках; его описание есть в документации Elasticsearch. Мой сервис при этом не обязан использовать Elasticsearch: метод и конкретный продукт — разные вещи.

«RAG умер»: что в этом споре полезного

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

В узкой задаче действительно можно передать модели несколько документов целиком. Иногда достаточно SQL-запроса, обычного поиска или вызова API. Не нужно строить отдельный RAG-сервис только потому, что на схеме осталось свободное место.

Но большой контекст не решает сам по себе четыре задачи: отбор нужного, актуальность, права доступа и стоимость повторной передачи материала. Если агент открыл поиск, получил документы и ответил по ним, функция retrieval никуда не исчезла. Изменился способ её организации.

Подход	Когда рассматривать	Что он не решает автоматически
Документы целиком в контексте	Несколько материалов, разовый анализ	Обновления, доступ и стоимость большого запроса
RAG	Много меняющихся источников, повторяющиеся вопросы	Качество исходных знаний и достоверность каждого вывода
SQL / API	Остаток, статус заказа, расчёт по текущим данным	Объяснение правил из неструктурированных документов
Fine-tuning	Устойчивый формат, стиль или специализированное поведение	Надёжное хранение вчерашних изменений и отзыв доступа

Эти подходы можно сочетать. Ассистент находит регламент через RAG, получает статус заказа через API и объясняет следующий шаг. Важен результат, а не чистота принадлежности к модному лагерю.

До выбора базы: разберём один рабочий разговор

Я бы начал не с закупки векторного хранилища, а с десяти-пятнадцати реальных обращений. Например, у службы поддержки:

Какие вопросы отнимают больше всего времени? Нужны сами формулировки из обращений, а не общее «хотим умный поиск».

Как сотрудник сейчас находит ответ? Открывает wiki, спрашивает старшего, сверяет PDF? Здесь обнаруживается исходная цена процесса.

Кто отвечает за действующее правило? Если два отдела поддерживают разные инструкции, модель не может сама назначить одну законной.

Какое действие человек должен выполнить после ответа? Объяснить клиенту условия, открыть заявку, назначить исполнителя? От этого зависит интерфейс и нужные интеграции.

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

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

RAG в небольшой компании

Учебный пример: сервисная компания, двадцать сотрудников, инструкции и каталог оборудования. Это иллюстрация архитектуры, не описание моего клиента.

Я начал бы с одного набора утверждённых документов и помощника для сотрудников. Коннектор забирает изменения, индекс хранит текст, ссылки и версии. API выполняет поиск и обращается к разрешённой модели. Интерфейс показывает ответ, источник и кнопку «не помогло».

Здесь может хватить одной базы с полнотекстовым и векторным поиском либо готового управляемого сервиса. Выбор зависит от существующего стека, навыков команды и требований к данным. Kubernetes не является вступительным экзаменом в RAG.

Самые важные назначения — владелец базы знаний и человек, который разбирает неудачные ответы. Без них пилот постепенно превращается в музей регламентов. Начальный объём определяют не числом всех файлов компании, а одним полезным сценарием: например, помощник по диагностике оборудования.

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

RAG в большой компании

В enterprise усложняется не только объём. Появляются разные владельцы знаний, системы доступа, версии продуктов, языки, юридические лица и требования к журналированию.

Участок	Небольшой пилот	Корпоративное внедрение
Источники	Одна утверждённая коллекция	Коннекторы к wiki, DMS, репозиториям; владельцы и SLA обновления
Права	Явно заданная группа пользователей	SSO, права на документ и фрагмент, отзыв доступа, изоляция подразделений
Обновления	Пакетная загрузка с контролем версии	Инкрементальная индексация, удаления, повторная обработка и мониторинг отставания
Качество	Контрольные вопросы одного процесса	Наборы по продуктам, языкам и ролям; анализ опасных ошибок
Эксплуатация	Один ответственный	Наблюдаемость, лимиты, резервирование, договорённости между командами

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

Индексацию полезно отделять от обслуживания запросов. Тогда большой импорт не блокирует ответы. Изменение модели эмбеддингов может потребовать перестроения индекса; нужны версия, контрольная оценка и возможность вернуться к предыдущему варианту.

Для вопросов о связях между сущностями иногда полезен граф знаний. Но GraphRAG не обязательная следующая ступень зрелости. Если проблема в неверном распознавании таблиц, дополнительный граф лишь красиво соединит неверные данные.

Как это выглядит в опубликованных внедрениях

Ring: поддержка с учётом языка и региона. В разборе Ring и AWS от 30 марта 2026 года описаны база проверенных материалов и RAG-помощник на Amazon Bedrock. Полезный урок для меня: сначала управляемый источник знаний и региональный контекст, затем масштабирование диалога. Это опубликованный кейс участников внедрения, а не мой независимый аудит его эффективности.

PDI Technologies: знания из разных систем. В инженерном разборе от 22 января 2026 года источники включают сайты, Confluence и SharePoint. Авторы отдельно обсуждают обработку документов и изображений. Здесь хорошо видна работа, которую слово «чат-бот» скрывает: материалы ещё надо привести к пригодному для поиска виду.

Моя практика: знания нескольких проектов. В LAF RAG Assistant я связываю документацию, код и историю решений. Человек или агент получает найденные фрагменты через API/MCP; при необходимости поверх поиска строится ответ. Это собственный рабочий инструмент. Перенос в компанию потребует отдельной адаптации источников и доступа, а не обещания «подключим папку, завтра всё готово».

Когда поиск становится ассистентом

Пользователь не просыпается с желанием «сделать retrieval». Ему надо ответить клиенту, подготовить изменение, разобраться в отказе или закончить заявку.

Пример: обращение в поддержку

01Понять ситуациюУточнить продукт и версию

02Найти основаниеПоказать пункт инструкции

03Подготовить действиеЗаполнить черновик заявки

04ПодтвердитьЧеловек разрешает отправку

Вернёмся к примеру с оборудованием. Слабая версия выдаёт пять фрагментов. Полезная уточняет модель устройства, находит действующее правило, показывает исключение и предлагает черновик обращения в нужную службу. Человек видит основания и подтверждает действие.

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

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

Как проверить, что всё это помогает

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

Проверка	Какой вопрос задаём
Поиск	Нужный источник оказался среди первых результатов?
Полнота контекста	Сохранились исключения, версия и условия применения?
Обоснованность	Каждое существенное утверждение подтверждается источником?
Отказ	Система не придумывает ответ, когда данных недостаточно?
Доступ	Пользователь и его история не получают закрытый материал?
Польза	Человек быстрее завершил задачу и не создал ошибочное действие?

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

Считаем полную стоимость: подготовку источников, распознавание, эмбеддинги, хранение, reranking, генерацию, проверки и работу владельца знаний. Стоимость токенов — одна строка сметы. Рядом измеряем время до проверенного ответа и количество обращений, которые всё равно пришлось разбирать вручную.

С чего начать завтра

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

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

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

Ваш ДПУПП