За полтора года я собрал не меньше десятка RAG-ботов по базе знаний PDF для разных компаний - от логистического каталога на 400 страниц до внутренних регламентов техподдержки завода. Задача всегда одна и та же: закинуть кипу PDF в бота и получить точные ответы со ссылкой на конкретный документ и страницу, а не общие фразы, которые модель придумала сама. Дальше - как это устроено на практике, какие грабли я собирал и во сколько такая система обходится бизнесу.
Что такое RAG-бот по базе знаний PDF и чем он отличается от обычного чат-бота
RAG расшифровывается как retrieval-augmented generation - поиск с дополнением генерации. Бот не хранит содержимое документов в весах модели, а перед каждым ответом ищет в базе релевантные куски текста и подкладывает их в запрос к языковой модели вместе с вопросом пользователя. Модель отвечает, опираясь только на найденные фрагменты, а не на то, что запомнила при обучении.
Разница с обычной загрузкой файлов в ChatGPT или Claude через интерфейс проекта заметна сразу, как только документов становится больше 20-30. Модель упирается в лимит контекстного окна, начинает путать документы между собой или отвечать общими словами вместо конкретной цитаты из инструкции. С RAG таких ограничений нет - база знаний может расти хоть до тысяч файлов, потому что в модель попадает не вся база, а только 3-5 нужных фрагментов под конкретный вопрос.
Fine-tuning модели под документы компании - вариант ещё менее практичный. Дорого, долго, и результат намертво зашит в веса: обновили регламент - модель всё равно отвечает по старой версии, пока не переобучите заново. RAG в этом смысле проще: добавил новый PDF в базу, посчитал эмбеддинг, бот через минуту уже отвечает с учётом нового документа.
Один из клиентов - производственная компания с 380 регламентами и инструкциями по оборудованию - раньше искал нужный пункт в PDF руками, тратя по 15-20 минут на обращение в техподдержку. После внедрения бота время сократилось до одного-двух ответов подряд, и каждый ответ шёл с указанием файла и номера страницы, откуда взята цитата.
Как подготовить PDF-документы компании для базы знаний
Половина проблем с качеством ответов RAG-бота растёт не из модели, а из того, как исходные PDF превратили в текст. Тут два отдельных этапа.
Извлечение текста и OCR для сканов
Для обычных текстовых PDF я беру PyMuPDF (fitz) или pdfplumber - они быстрее и точнее держат структуру таблиц, чем более простые библиотеки. Многостраничные каталоги с таблицами и многоколоночной вёрсткой почти всегда требуют отдельной логики извлечения под конкретный тип документа - универсальный парсер один на всё не работает.
Отсканированные документы - старые акты, чертежи, приказы с печатью - нужно прогонять через OCR. Tesseract бесплатный, но на кириллице и плохом качестве скана даёт заметно больше ошибок распознавания, чем платные API вроде Yandex Vision или Google Document AI. На проектах, где качество сканов было так себе, я в итоге переходил на платное распознавание - экономия на бесплатном движке потом выходит боком в виде неточных ответов бота.
Разбивка текста на чанки
Текст режется на куски по 500-800 токенов с перекрытием 100-150 токенов - без перекрытия бот теряет контекст на границе абзацев. К каждому чанку я привязываю метаданные: имя файла, номер страницы, раздел документа - именно это потом даёт боту возможность указывать источник, а не выдумывать его.
Таблицы обычно чанкую отдельно от связного текста: если склеить таблицу с обычным абзацем, эмбеддинг получается смазанным и поиск начинает промахиваться. Готовый скрипт на Python для парсинга и чанкинга PDF с сохранением метаданных есть в библиотеке готовых скриптов - экономит день-два на старте, если собираете пайплайн сами.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Векторная база данных и эмбеддинги - как бот ищет нужный кусок текста
Каждый чанк превращается в эмбеддинг - вектор чисел, который отражает смысл текста. При вопросе пользователя система считает эмбеддинг вопроса и ищет в базе ближайшие по косинусному расстоянию векторы чанков. Чем ближе вектора, тем релевантнее кусок текста для ответа модели.
Для эмбеддингов беру text-embedding-3-small от OpenAI или voyage‑3 - оба нормально работают с русским языком, разница на практике в основном в цене запроса и скорости, а не в качестве поиска. Для хранения векторов выбор зависит от масштаба проекта:
| База | Где хостится | Цена | Когда беру |
|---|---|---|---|
| Chroma | self-hosted / локально | бесплатно | MVP, до 5-10 тысяч чанков, без внешних зависимостей |
| pgvector | расширение к PostgreSQL | цена сервера БД | когда у клиента уже есть Postgres и не хочется плодить сервисы |
| Qdrant | self-hosted или облако | от бесплатного тарифа | средние и крупные базы, нужен быстрый фильтр по метаданным |
| Pinecone | только облако | от платного тарифа провайдера | когда клиент готов платить за managed-сервис и не думать про инфраструктуру |
Как собрать RAG-пайплайн: от PDF до ответа с указанием источника
Пайплайн состоит из пяти шагов, вокруг которых крутится вся система:
- PDF попадает в парсер, текст режется на чанки с метаданными.
- Чанки прогоняются через модель эмбеддингов и складываются в векторную базу.
- Вопрос пользователя тоже превращается в эмбеддинг.
- Векторный поиск достаёт 3-5 самых близких чанков.
- Чанки и вопрос уходят в промпт языковой модели, которая формирует ответ с цитатой источника.
Каркас на Python без лишних абстракций выглядит так:
import anthropic
client = anthropic.Anthropic()
def answer(question, retrieved_chunks):
context = "nn".join(
f"[{c['source']}, стр. {c['page']}]n{c['text']}"
for c in retrieved_chunks
)
prompt = (
f"Ответь на вопрос только на основе контекста ниже. "
f"Укажи источник.nnКонтекст:n{context}nnВопрос: {question}"
)
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
)
return response.content[0].textДля быстрого прототипа без своего бэкенда собираю то же самое в n8n: нода Webhook принимает вопрос, нода векторного поиска (Supabase или Pinecone) достаёт чанки, HTTP Request дёргает Claude API, ответ уходит обратно в Telegram или на сайт. Один такой пайплайн я собрал клиенту за 4 дня вместо трёх недель на кастомном бэкенде - но как только логика начинает ветвиться по типу документа или нужна сложная фильтрация, n8n становится тесно и проще написать код руками.
Куда подключить готового RAG-бота - Telegram, сайт, CRM
Telegram чаще всего собираю на aiogram - свой бот с вебхуком на сервере, без ограничений на количество сообщений, которые есть у готовых конструкторов.
Для сайта - виджет, который вставляется скриптом в футер: для Tilda это блок с кастомным HTML-кодом, для WordPress и WooCommerce - подключение через functions.php или отдельный плагин-обвязку. Делал такой виджет для интернет-магазина на WooCommerce, где бот отвечал покупателям по PDF-инструкциям к товарам и характеристикам - снял часть однотипных вопросов с поддержки ещё до оформления заказа.
Для внутренней поддержки бота встраивают в CRM - Bitrix24 или amoCRM, чтобы сотрудник искал ответ по регламентам прямо из карточки обращения, не переключаясь между вкладками.
Сколько стоит обучить ИИ-бота на документах компании и сколько это займёт
Смета зависит от объёма документов, каналов подключения и того, нужна ли интеграция с CRM или сайтом. Ориентир по моим услугам:
| Задача | Цена |
|---|---|
| Чат-бот с базой знаний (RAG) | от 50 000 ₽ |
| AI-интеграция (Claude API / OpenAI / RAG) отдельным модулем | от 50 000 ₽ |
| Telegram-бот как канал | от 30 000 ₽ |
| Парсинг и автоматизация PDF на Python | от 20 000 ₽ |
| Автоматизация пайплайна в n8n | от 25 000 ₽ |
| Техподдержка после запуска | от 15 000 ₽/мес |
На MVP с базой до 100-150 PDF и одним каналом (например, Telegram) уходит 2-3 недели. Проекты крупнее - 500+ документов, несколько источников, интеграция с CRM - растягиваются на 4-6 недель за счёт этапа чистки и разметки документов, который занимает больше времени, чем сама разработка пайплайна.
На рынке у веб-студий похожий проект по цене обычно от 150 000 до 400 000 ₽ - в смету закладывают проектную команду и длинную discovery-фазу. Я работаю соло, поэтому смета компактнее и без наценки за менеджмент, которого тут нет.
Чат-бот с базой знаний
AI / RAG
от 50 000 ₽
Подробнее →Частые вопросы
Сколько PDF-документов может обработать RAG-бот без потери качества?
Технического потолка нет - база на 5 тысяч документов работает так же стабильно, как на 50, потому что в модель на каждый запрос попадает не вся база, а всего несколько найденных чанков. Узкое место - качество самого поиска: если документы плохо структурированы или чанкинг сделан небрежно, релевантность начинает проседать уже на паре сотен файлов, независимо от общего объёма.
Нужно ли дообучать (fine-tuning) модель, если уже есть RAG?
В подавляющем большинстве проектов - нет. RAG закрывает задачу подстановки актуальных фактов из документов, а fine-tuning имеет смысл только когда нужно поменять саму манеру ответа модели или научить её специфическому формату вывода, который не получается задать промптом. Для базы знаний PDF это почти никогда не требуется.
Как бот узнаёт про новые документы, если они появляются после запуска?
Новый PDF проходит тот же парсинг и чанкинг, эмбеддинги добавляются в существующую векторную базу - переобучать модель или пересобирать пайплайн не нужно. На проектах с частым обновлением документов я обычно настраиваю отдельный скрипт или n8n-сценарий, который забирает файлы из папки или CRM по расписанию и сам прогоняет их через пайплайн.
Работает ли RAG-бот с русскоязычными PDF и плохими сканами?
Да, но с оговоркой на OCR: качество распознавания сканов на кириллице у бесплатных инструментов вроде Tesseract заметно ниже, чем у платных API распознавания. Если исходники - это фотографии старых бумажных документов, закладывайте на этап OCR отдельное время и, вероятнее всего, платный инструмент распознавания - иначе неточности перекочуют дальше по всему пайплайну и осядут в ответах бота.