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

Что реально можно успеть за два дня

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

Шаг 1. Корпус и порядок в источниках

Не пытайтесь подключить сразу всё: 1С, Confluence, файловые шары и почту. Возьмите один-два типа документов — регламенты, инструкции, договоры или техдокументацию. Приведите их к тексту: PDF и DOCX конвертируйте в markdown, сканы прогоните через OCR (Tesseract, PaddleOCR, Docling). Отдельно удалите дубли и старые редакции: значительная часть мусорных ответов в RAG — это устаревшие версии одного и того же документа.

Шаг 2. Стек: векторная база и эмбеддинги

Для прототипа достаточно pgvector в уже существующем Postgres или Qdrant, поднятого в Docker. По эмбеддингам хорошо работают с русским bge-m3 и multilingual-e5-large — они запускаются локально через ONNX или на одной GPU. Если политика безопасности запрещает внешние API, держите в контуре и эмбеддинги, и генерацию: сегодня это реалистично на моделях класса Qwen или на российских облачных LLM с закрытым контуром.

Шаг 3. Чанкинг и метаданные

Резать текст «по 500 токенов» — рабочая база, но лучше резать по структуре: заголовок, пункт, таблица, раздел договора. Перекрытие в 10–15% помогает не терять смысл на границах. Каждому чанку присвойте метаданные: файл, раздел, дата, версия, подразделение, права доступа. Без них вы не отфильтруете выдачу по отделу и не покажете пользователю внятную ссылку на первоисточник.

Шаг 4. Гибридный поиск и реранкер

Чистый векторный поиск плохо ловит аббревиатуры, номера приказов, артикулы и фамилии. Добавьте лексический поиск — BM25 в Postgres или OpenSearch — и объединяйте результаты через reciprocal rank fusion. Топ-50 кандидатов прогоняйте через реранкер вроде bge-reranker-v2-m3: это самый дешёвый способ заметно поднять точность выдачи.

Шаг 5. Ответ с цитатами и проверка качества

Промпт формулируйте жёстко: отвечай только по предоставленному контексту, при нехватке данных скажи об этом прямо, всегда указывай источник. Затем соберите 30–50 реальных вопросов сотрудников — не придуманных, а из чатов поддержки и обращений в бухгалтерию. Считайте hit rate (доля вопросов, где нужный документ попал в топ) и долю ответов с корректной цитатой. Это и есть метрика вашего прототипа.

Где прототип ломается на проде

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

Как мы можем помочь

Мы в АПС собираем RAG-контуры под ключ: аудит корпуса, пайплайны OCR и индексации, гибридный поиск с реранкером, права доступа, интеграции с 1С и CRM, локальные модели в закрытом контуре. Начинаем с быстрого пилота на ваших документах — чтобы вы увидели качество ответов до старта большого проекта. Обсудить проект