Бот по PDF и регламентам: как RAG работает на практике

История началась с одного звонка от HR-директора крупной производственной компании. «У нас 400 страниц внутренних регламентов, – говорила она, – и сотрудники задают одни и те же вопросы по сто раз в неделю. Можно ли сделать бота, который будет отвечать вместо меня?»

Казалось бы, задача простая. Загрузили документы в GPT – и готово. Но когда мы попробовали это сделать, столкнулись с проблемой, которая знакома каждому, кто работал с большими языковыми моделями. Бот начал выдумывать. Уверенно, убедительно, с цитатами – которых не существовало. На вопрос «сколько дней отпуска положено после 5 лет работы» он отвечал «28 дней», хотя в регламенте было написано совсем другое.

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

Решением стал RAG – Retrieval Augmented Generation. Подход, при котором модель не выдумывает ответы, а сначала находит релевантные фрагменты документов и только потом формулирует ответ на их основе. В этой статье я расскажу, как это работает на практике, какие подводные камни ждут при внедрении и как добиться того, чтобы бот по регламентам действительно помогал, а не вводил в заблуждение.

Почему обычный ChatGPT не подходит для работы с документами

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

Первое – это контекстное окно. Даже у самых продвинутых моделей есть лимит на количество текста, который они могут обработать за один раз. GPT-4 Turbo принимает до 128 тысяч токенов – это примерно 100 тысяч слов или 300-400 страниц текста. Звучит много, но корпоративная документация легко может превышать этот объём в разы. Регламенты, инструкции, политики, FAQ – всё это быстро накапливается.

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

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

И четвёртое – актуальность. Документы меняются. Регламенты обновляются, добавляются новые политики, исправляются ошибки. Если вы один раз загрузили документы в модель, она не будет знать об изменениях. А если используете модель через API – она вообще не «помнит» ваши документы между сессиями.

Что такое RAG и как он решает эти проблемы

RAG расшифровывается как Retrieval Augmented Generation – генерация с дополнением поиском. Идея проста и элегантна: вместо того чтобы загружать все документы в модель, мы сначала находим только релевантные фрагменты и подсовываем их вместе с вопросом пользователя.

Представьте это как работу хорошего референта. Когда вы спрашиваете «какие документы нужны для оформления отпуска», референт не пересказывает вам весь трудовой кодекс и все внутренние регламенты. Он находит нужный раздел, открывает его и показывает конкретный параграф с ответом. RAG работает по тому же принципу.

Такой подход решает все перечисленные проблемы. Контекстное окно? Мы используем только несколько релевантных фрагментов, а не весь массив документов. Стоимость? Снижается в разы, потому что объём передаваемого текста минимален. Галлюцинации? Модель видит конкретный текст источника и может его процитировать. Актуальность? Обновили документ – переиндексировали, и бот уже знает новую информацию.

Архитектура RAG-системы: из чего она состоит

Когда я впервые столкнулся с RAG, архитектура показалась мне сложной. Столько компонентов, столько терминов – эмбеддинги, векторные базы, чанкинг. Но на практике всё оказывается логичным, когда понимаешь роль каждого элемента.

Парсер документов

Первый компонент – это система, которая извлекает текст из документов. Казалось бы, что тут сложного? Но документы бывают разные: PDF с текстовым слоем и без него, Word-файлы со сложным форматированием, таблицы Excel, презентации PowerPoint, страницы Confluence или Notion. Для каждого формата нужен свой подход.

Особенно коварны PDF-файлы. Если документ создан из текстового редактора – текст извлекается легко. Если это скан – нужен OCR (оптическое распознавание). А если PDF содержит сложные таблицы или схемы – текст может извлечься в неправильном порядке, потому что PDF хранит не «документ», а набор инструкций для отрисовки.

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

Чанкер (разбиение на фрагменты)

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

Размер чанка – это баланс. Слишком маленькие фрагменты (по одному предложению) теряют контекст: «28 дней» без окружающего текста непонятно, к чему относится. Слишком большие фрагменты (по несколько страниц) снижают точность поиска и занимают много места в контекстном окне модели. Оптимальный размер обычно – 200-500 слов, но зависит от характера документов.

Умные чанкеры учитывают структуру документа: стараются не разрывать абзацы посередине, сохраняют заголовки вместе с текстом раздела, обрабатывают таблицы как единое целое. Также часто используется перекрытие (overlap) – когда конец одного чанка повторяется в начале следующего. Это помогает не потерять информацию на границах.

Модель эмбеддингов

Эмбеддинг – это числовое представление текста в виде вектора. Звучит абстрактно, но суть простая: модель читает текст и выдаёт набор чисел, который «кодирует» смысл этого текста. Тексты с похожим смыслом получают похожие векторы.

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

Выбор модели эмбеддингов влияет на качество поиска. Для русского языка хорошо работают multilingual-модели от OpenAI (text-embedding-3-small/large), Cohere, или открытые модели типа E5, BGE. Важно, чтобы модель была обучена на текстах, похожих на ваши документы.

Векторная база данных

Эмбеддинги нужно где-то хранить и по ним быстро искать. Для этого существуют специализированные векторные базы данных: Pinecone, Weaviate, Qdrant, Chroma, Milvus. Можно использовать и обычный PostgreSQL с расширением pgvector – для небольших объёмов этого достаточно.

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

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

Языковая модель (LLM)

Собственно, генеративная модель, которая формулирует ответ. Это может быть GPT-4, Claude, GigaChat, YandexGPT или открытые модели типа Llama, Mistral. Выбор зависит от требований к качеству, стоимости и приватности данных.

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

Подготовка документов: что загружать и как

Качество RAG-системы напрямую зависит от качества исходных документов. «Мусор на входе – мусор на выходе» работает здесь в полной мере. Поэтому перед загрузкой документов стоит провести их ревизию.

Метаданные – это важно

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

Например, если пользователь спрашивает про командировки, система может сначала искать в документах с тегом «командировки» или «HR-политики», а не во всей базе. Это повышает релевантность и снижает риск найти что-то не то.

Типичные метаданные для корпоративных документов: название документа, дата последнего обновления, отдел-владелец, категория (HR, финансы, IT), уровень конфиденциальности. Продумайте схему метаданных до загрузки – добавлять их потом сложнее.

Почему бот всё равно «врёт» – и как это чинить

Вот мы настроили RAG, загрузили документы, бот отвечает. Но иногда ответы всё равно неверные. Или верные, но не про то. Или частично верные. Давайте разберём типичные проблемы и способы их решения.

Проблема 1: Неправильный retrieval (нашли не те документы)

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

Как диагностировать: логируйте найденные фрагменты и смотрите, что возвращается на типичные запросы. Если релевантный фрагмент есть в базе, но не попадает в топ – проблема в поиске.

Как чинить:

• Увеличьте количество возвращаемых фрагментов (top-K) – может, нужный фрагмент на 6-м месте, а вы берёте только 5.
• Добавьте reranking – второй этап ранжирования с помощью более точной модели (Cohere Rerank, BGE Reranker).
• Улучшите чанкинг – возможно, релевантная информация разбита между чанками или утонула в большом фрагменте.
• Попробуйте гибридный поиск – комбинация семантического поиска (по эмбеддингам) и классического BM25 (по ключевым словам) часто даёт лучшие результаты.

Проблема 2: Галлюцинации при генерации

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

Как чинить:

• Ужесточите промпт: явно запретите добавлять информацию, которой нет в контексте. Фразы типа «отвечай ТОЛЬКО на основе предоставленных документов» работают.
• Требуйте цитирования: попросите модель указывать, из какого фрагмента взята информация. Это дисциплинирует.
• Снизьте температуру: параметр temperature влияет на «креативность» модели. Для RAG лучше низкие значения (0.1-0.3).
• Добавьте фразу «если информации нет – скажи об этом»: модели склонны отвечать, даже когда не знают. Явное разрешение признаться в незнании помогает.

Проблема 3: Противоречия в источниках

Что если в разных документах написано разное? Старая версия регламента говорит одно, новая – другое. Или разные отделы создали противоречивые инструкции. Модель получает оба фрагмента и не знает, чему верить.

Как чинить:

• Удалите устаревшие версии документов из базы. Это кажется очевидным, но часто забывается.
• Используйте метаданные с датами и приоритетами: научите систему отдавать предпочтение более свежим документам.
• В промпте укажите: при противоречиях – сообщать об этом, а не выбирать произвольно.

Верификация ответов: как убедиться, что бот не врёт

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

Метрики качества RAG: что измерять

Нельзя улучшить то, что не измеряешь. Для RAG-систем есть несколько ключевых метрик, которые стоит отслеживать.

Для автоматизации оценки существуют фреймворки: RAGAS, TruLens, DeepEval. Они позволяют оценивать качество RAG без ручной разметки, используя LLM в качестве судьи. Это не идеально, но даёт возможность отслеживать регрессии и сравнивать разные конфигурации.

Практический совет: начните с простого. Соберите 50-100 типичных вопросов пользователей, напишите для них эталонные ответы, и регулярно прогоняйте через систему. Это даст понимание, в каких случаях система работает хорошо, а где нужны улучшения.

Обновление базы знаний: как поддерживать актуальность

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

Варианты обновления

Полная переиндексация по расписанию. Самый простой подход: раз в день или неделю система забирает все документы из источника и переиндексирует с нуля. Подходит для небольших баз (до нескольких тысяч документов) и случаев, когда изменения нечастые. Минус – нагрузка на систему и время, когда данные могут быть неактуальны.

Инкрементальное обновление. Система отслеживает, какие документы изменились, и переиндексирует только их. Требует механизма отслеживания изменений (через webhook, сравнение хешей или дат модификации). Сложнее в реализации, но эффективнее для больших баз.

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

Удаление устаревших документов

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

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

Практический кейс: бот по HR-регламентам

Давайте вернёмся к той истории, с которой я начал. HR-директор производственной компании с 400 страницами регламентов. Как мы решили её задачу?

Исходная ситуация

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

Пользователи: 2000 сотрудников. Типичные вопросы: «сколько дней отпуска мне положено», «как оформить командировку», «кто согласовывает обучение», «какая компенсация за использование личного автомобиля».

Проблема: HR-отдел из 5 человек тратил около 30% времени на ответы на типовые вопросы. Одни и те же вопросы по 10-20 раз в неделю.

Решение

Мы развернули RAG-систему на базе OpenAI API и Qdrant в качестве векторной базы. Документы загружались из корпоративного SharePoint с автоматическим обновлением раз в сутки.

Чанкинг настроили с учётом структуры документов: каждый пункт политики – отдельный чанк с заголовком раздела в качестве контекста. Размер чанка – около 300-500 слов с перекрытием в 50 слов.

Промпт для модели содержал строгие инструкции: отвечать только на основе документов, указывать источник, при неуверенности – рекомендовать обратиться в HR-отдел лично.

Бот был доступен в Telegram и через виджет на внутреннем портале. Интерфейс показывал не только ответ, но и ссылку на документ-источник.

Результаты

Через месяц после запуска бот обрабатывал около 150 вопросов в неделю. Точность ответов (по оценке HR-отдела) – около 85%. На 15% вопросов бот корректно отвечал «точной информации не нашёл» и рекомендовал обратиться к HR-специалисту.

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

Важный момент: мы не позиционировали бота как замену HR-отдела. Это инструмент для быстрых ответов на простые вопросы. Сложные случаи по-прежнему решаются с людьми. Такой подход снял опасения сотрудников, что бот будет давать неверную информацию по важным вопросам.

Выбор инструментов: что использовать

На рынке много инструментов для создания RAG-систем. Вот краткий обзор основных категорий.

Готовые платформы

Если хотите быстро и без глубокого погружения в технологии – есть SaaS-решения: ChatGPT Enterprise с загрузкой документов, Claude for Work, российские GigaChat и YandexGPT с функцией работы с документами. Плюсы: быстрый старт, не нужна своя инфраструктура. Минусы: ограниченная кастомизация, данные уходят на внешний сервис (может быть проблемой для конфиденциальных документов).

Фреймворки для разработки

LangChain и LlamaIndex – два самых популярных фреймворка для построения RAG-пайплайнов. Они предоставляют готовые компоненты: загрузчики документов, чанкеры, интеграции с векторными базами, промпт-темплейты. Позволяют собрать кастомное решение с полным контролем над каждым этапом.

LangChain более универсален и поддерживает разные сценарии (не только RAG). LlamaIndex более специализирован именно на работе с документами и имеет более продвинутые возможности для сложных структур данных.

Векторные базы данных

Для хранения эмбеддингов нужна векторная база. Популярные варианты:

• Pinecone – managed-сервис, простой старт, хорошо масштабируется. Платный.
• Qdrant – open-source, можно развернуть самостоятельно или использовать облако. Хорошая производительность.
• Weaviate – open-source, встроенная поддержка гибридного поиска, модули для разных моделей эмбеддингов.
• Chroma – легковесный, хорош для прототипов и небольших проектов.
• pgvector – расширение для PostgreSQL. Если у вас уже есть Postgres – не нужна отдельная база.

Модели эмбеддингов

OpenAI text-embedding-3-small/large – хорошее качество, простой API, платно за использование. Cohere Embed – альтернатива от Cohere, есть модели для разных языков. Открытые модели (E5, BGE, BAAI) – можно запустить локально, бесплатно, но требуют инфраструктуры.

Для русского языка важно выбирать multilingual-модели. Модели, обученные только на английском, будут работать заметно хуже с русскоязычными документами.

Типичные ошибки при внедрении RAG

За время работы с RAG-проектами я насмотрелся на разные ошибки. Вот те, которые встречаются чаще всего.

Ещё одна частая ошибка – завышенные ожидания. RAG – это не магия. Система не будет отвечать на вопросы, ответов на которые нет в документах. Не будет понимать неявный контекст. Не заменит эксперта в сложных случаях. Это инструмент для быстрого доступа к информации, а не универсальный консультант.

Когда RAG – не лучший выбор

RAG отлично работает для определённого класса задач. Но есть сценарии, где другие подходы будут эффективнее.

Если документов мало и они стабильны – проще сделать обычную базу знаний с поиском по ключевым словам. FAQ из 50 вопросов не требует нейросетей.

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

Если критична 100% точность – RAG даёт высокую, но не абсолютную точность. Для медицинских, юридических или финансовых решений, где ошибка недопустима, нужны дополнительные механизмы верификации или human-in-the-loop.

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

В итоге: RAG – это инструмент, а не волшебство

RAG – толковый подход для ботов, которые отвечают по документам. Решает основные боли: ограниченный контекст, дорогие токены, галлюцинации, устаревшую инфу.

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

Если только начинаете – не пытайтесь сделать всё и сразу. Возьмите десяток-два ключевых документов, настройте простой пайплайн, погоняйте на реальных вопросах. Соберите фидбек, подкрутите, расширьте. Итеративный подход работает лучше, чем попытка сразу соорудить идеальную систему.

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

Полезные материалы

• База знаний и RAG – как снизить нагрузку на поддержку
• RAG в реальном бизнесе – архитектура, источники данных, метрики
• Борьба с галлюцинациями LLM – как заставить модель отвечать по фактам
• Обучить AI-бота за 1 день – практический гайд
• Безопасное внедрение LLM – промпт-инжиниринг, ограничения, оценка качества