RAG в ИИ: что это и как локальная модель отвечает по документам

RAG в ИИ — что это простыми словами

RAG расшифровывается как retrieval-augmented generation: генерация с извлечением. Вместо того чтобы полагаться только на сведения в параметрах модели, приложение сначала ищет относящиеся к вопросу записи во внешнем корпусе и передаёт найденный контекст генератору. В оригинальной работе Lewis и соавторов генератор сочетается с извлекаемой непараметрической памятью s1.

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

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

1. Получить и разобрать документы. Из PDF, текста или другого источника получают пригодное для поиска представление. Например, Docling документирует преобразование файлов и экспорт в Markdown; для таблиц и сканов сверьте извлечённые поля с оригиналом, иначе поиск унаследует ошибку разбора s6.
2. Подготовить индекс. Разделите материал на фрагменты с указанием документа и версии, затем настройте поиск. Типичный вариант — получить числовые представления (эмбеддинги) фрагментов и сохранить их с метаданными. LlamaIndex описывает загрузку, индексацию и хранение как отдельные этапы s2.
3. Найти контекст по вопросу. Приложение извлекает подходящие фрагменты и передаёт их модели с запросом. Индекс и способ поиска определяют, какие сведения модель вообще увидит. Qdrant документирует как плотный семантический, так и разреженный поиск по словам; гибридный вариант полезно сравнить на вопросах с точными названиями и номерами s2 s4.
4. Сверить ответ. Проверьте отдельно, нашёлся ли нужный фрагмент, совпадает ли цитата с исходным документом и поддерживает ли каждый существенный вывод ответа найденный текст. Ragas называет последнюю проверку faithfulness — согласованностью ответа с извлечённым контекстом; она не оценивает сама по себе полноту и истинность исходных данных s5.

Эмбеддинги — способ представить фрагменты и запрос векторами для семантического сравнения, а не замена исходному тексту документа. Ollama документирует /api/embed для их получения; Qdrant описывает и собственные варианты inference в облаке, и клиентский FastEmbed. Нельзя свести все RAG-архитектуры к одному векторному хранилищу или утверждать, будто поиск всегда обязан получать векторы только вне него s3 s4.

Подойдёт ли локальная модель

Локальный контур — архитектурный выбор: разбор, эмбеддинги, индекс, генератор, хранилище исходников и журналы доступа должны быть размещены и проверены согласно требованиям к данным. Ollama может создавать эмбеддинги через API, а Open WebUI документирует интерфейс загрузки документов и просмотр использованного контекста. Наличие этих возможностей не доказывает, что выбранная конфигурация изолирована от сети, правильно разделяет права пользователей или качественно отвечает на русском корпусе s3 s8. Необходимо проверить фактические настройки, версии и движение данных.

RAG разумен, когда вопрос опирается на меняющиеся или большие разрешённые документы и важна проверяемая ссылка на конкретный источник. Если задача — выдерживать постоянный формат ответа или изменить поведение модели без внешней фактуры, сравните промпт, готовую модель и дообучение/LoRA на одних вопросах. Это выбор метода для проверки, а не обещание превосходства RAG s1.

Что может пойти не так

• Неверно разобранная таблица, пропущенная страница или старая версия документа дают поиск по неправильной базе; сверяйте извлечённый текст с оригиналом и храните версию s6.
• Семантический поиск может упустить точный артикул, дату или номер договора; сравните его с гибридным поиском на характерных вопросах s4.
• Модель может уверенно добавить несодержащееся в источнике утверждение. Проверяйте каждое существенное предложение ответа по возвращённому фрагменту; отдельный разбор оценки RAG поможет разделить сбой поиска и сбой генерации s5.
• Найденный документ может содержать вредоносные инструкции для модели. OWASP относит косвенную prompt injection через документы и сайты к угрозам LLM-приложений: найденный текст следует считать данными, а не доверенной командой s7.
• Поиск по общему индексу не становится разграниченным доступом автоматически. Для проверки на своих данных заведите пользователей с разными правами и убедитесь, что чужие документы не попадают ни в найденные фрагменты, ни в ответ. Это предлагаемый тест, не проведённый Modelium аудит.

Как проверить на своих документах

Возьмите разрешённый небольшой корпус с версиями файлов и заранее запишите несколько вопросов: один с явным ответом, один с номером/идентификатором, один без ответа, один по устаревшей редакции. Для каждого запишите ожидаемый фрагмент и страницу оригинала. После индексации оцените, найден ли правильный текст, верна ли привязка цитаты и отвечает ли модель только на основании полученного контекста. Повторите после замены одного документа и на учётной записи без доступа. Это редакционный протокол; собственных результатов или измеренной точности Modelium здесь нет.

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