Шесть слоёв образуют архитектуру RAG-системы, от загрузки документов до генерации ответа с цитатой на источник, и у каждого слоя своя точка отказа. Здесь — технический разбор слой за слоем, для инженера или технического заказчика, что собирает контур сам или проверяет подрядчика.
Шесть слоёв системы
RAG-система — цепочка из шести отдельных слоёв, собранных в один конвейер: загрузка и очистка документов, разбиение на чанки, эмбеддинги и векторное хранилище, гибридный поиск, реранкинг и генерация ответа с цитатой на источник.
Материал для руководителя о том, зачем компании такая база знаний вообще, — в статье RAG-база знаний для компании. Здесь — тот же контур с другой стороны: слой за слоем, для того, кто собирает систему руками или принимает работу у подрядчика.
- Загрузка и очистка — документы попадают в систему, форматирование и мусор убираются перед разбиением.
- Чанкинг — текст режется на фрагменты подходящего размера с учётом смысловых границ.
- Эмбеддинги и векторное хранилище — каждый фрагмент превращается в числовой вектор и складывается в базу для поиска по смыслу.
- Поиск, реранкинг, генерация — система находит релевантные фрагменты, уточняет порядок по значимости и формирует ответ с цитатой.
Порядок слоёв в этой цепочке фиксированный — пропустить чанкинг или векторизацию нельзя, а вот реранкинг и версионирование можно добавить позже, когда станет ясно, где именно рвётся качество ответа.
Загрузка и чанкинг
Первая точка отказа — качество исходных документов: скан низкого разрешения, таблица без структуры, PDF с ломаной вёрсткой дают на выходе фрагменты с обрывками фраз и потерянными числами. Очистка на входе решает больше, чем кажется на старте проекта — фундамент точности закладывается именно здесь.
Размер чанка — компромисс: слишком мелкий фрагмент теряет контекст вокруг факта, слишком крупный тащит за собой лишнее и размывает релевантность поиска. Разбиение по смысловым границам (абзац, пункт договора, раздел инструкции) обычно точнее, чем фиксированная длина в символах.
Метаданные документа — дата, автор, раздел, версия — сохраняют рядом с каждым чанком уже на этапе загрузки: без них реранкинг и фильтрация по свежести документа на более позднем этапе становятся заметно сложнее. Отдельный смежный вопрос — куда девать документы без чёткой структуры вроде переписки в мессенджере или рукописных заметок, отсканированных как есть.
- Скан или фото документа — отдельный шаг распознавания текста перед чанкингом, иначе система режет мусор вместо смысла.
- Таблицы и структурированные данные — часто требуют отдельной логики разбора, обычный чанкинг по абзацам их ломает.
- Версии документа — обновление источника должно обновлять и его векторное представление, иначе поиск находит устаревшую версию.
Поиск и реранкинг
Векторный поиск находит фрагменты, близкие по смыслу — сильная сторона для расплывчатых формулировок запроса и слабая для точных терминов, артикулов или номеров статей. Гибридный поиск компенсирует эту слабость, комбинируя векторный поиск с поиском по ключевым словам: термин и смысл ловятся вместе.
Условный пример: запрос «что говорит регламент про отпуск за свой счёт» векторный поиск находит по смыслу даже без точного совпадения формулировки, а запрос с конкретным номером пункта или артикулом товара находит вернее поиск по ключевым словам — гибридная схема закрывает оба случая одним контуром.
| Слой | Что делает | Типичная точка отказа |
|---|---|---|
| Векторный поиск | Ищет по смысловой близости | Пропускает точные термины и номера |
| Поиск по ключевым словам | Ищет точное совпадение | Пропускает синонимы и перефразировки |
| Реранкинг | Уточняет порядок найденных фрагментов по значимости | Слишком узкое окно кандидатов на входе |
Реранкинг — отдельная модель поверх результатов первичного поиска, что пересортировывает найденные фрагменты по релевантности конкретному запросу. Без этого шага система порой подаёт в ответ фрагмент, что формально прошёл поиск, а по сути мимо вопроса.
Генерация и цитаты
Финальный слой — модель формирует ответ из найденных фрагментов, и вместе с ответом система возвращает ссылку на источник: документ, раздел, дата версии. Цитата экономит время проверки: ответ сверяется с источником за секунды, без повторного чтения документа целиком.
Оценка качества всей цепочки строится на трёх вопросах: находит ли поиск нужный фрагмент, отвечает ли генерация именно на поставленный вопрос и совпадает ли цитата с реальным источником. Тестовый набор вопросов с эталонными ответами прогоняют через систему регулярно — вручную на старте, автоматически на потоке.
Набор эталонных вопросов пересобирают по мере роста базы документов — вопросы, что покрывали систему на пятидесяти документах, часто теряют актуальность на пятистах: появляются новые темы, что тестовый набор на старте вовсе избегал. Отдельно фиксируют долю ответов без цитаты вообще — это почти всегда сигнал провала на слое поиска, а небрежность генерации тут обычно ни при чём.
Какие документы компании чаще всего ищут вручную сотрудники?
Облако или свой контур
Облачная сборка — векторная база и модель у внешнего провайдера — быстрее в развёртывании и дешевле на старте: сервер и команда поддержки инфраструктуры пока лишние. Свой контур — база и модель на собственном сервере — оправдан, когда данные строго внутренние или объём запросов делает облачный тариф дороже владения железом.
- Малый объём документов и быстрый пилот — облако забирает меньше времени на старт.
- Строго внутренние данные (медицина, финансы, гостайна) — свой контур снимает вопрос размещения данных за пределами компании.
- Растущий объём запросов на потоке — стоимость облачного тарифа сравнивают со стоимостью владения собственной инфраструктурой на дистанции.
Смешанный вариант тоже встречается на практике — часть контура в облаке (генерация), часть на своём сервере (хранилище с чувствительными данными), и такая связка снимает часть компромиссов сразу. Миграция между вариантами задним числом обходится дороже выбора на старте: смена векторного хранилища означает пересчёт всех эмбеддингов заново, а обычный перенос файлов с сервера на сервер здесь ни при чём.
Альтернатива RAG для части задач — дообучение модели на корпусе компании вместо поиска по базе на каждый запрос; когда какой подход выбрать — разбор в статье RAG или дообучение модели для компании.
Первый шаг — тестовый корпус из пятидесяти-ста документов и десяти вопросов с заранее известным правильным ответом. Прогнать корпус через минимальную сборку (загрузка, чанкинг, векторный поиск, генерация без реранкинга), посмотреть, где рвётся цепочка, и добавлять слои по одному — гибридный поиск, реранкинг, версионирование — точечно под обнаруженный разрыв, лишние слои про запас только замедляют систему.
Оценка состава работ под конкретную задачу компании — тема отдельного разговора; тема работы с документами через нейросети собирает эти задачи в одном месте, а состав работ под вашу архитектуру считаем на Discovery-созвоне.