1. Нет разбиения на чанки
Если положить в vector store целый длинный документ, эмбеддинг станет слишком общим. Поиск будет возвращать «вроде похожий» текст, но не точный фрагмент.
RecursiveCharacterTextSplitter, сохраняйте source, page, start_index и другие метаданные.2. Слишком маленькие или слишком большие чанки
Маленькие чанки теряют смысл, большие чанки добавляют шум и расходуют токены. Настройки нужно подбирать на тестовых вопросах.
3. Устаревшая embedding-модель
Старый учебный код может перестать работать из-за выключенной модели. Не зашивайте модель в десятки файлов: вынесите имя модели в конфиг и сверяйте docs перед запуском.
4. Документы и запросы эмбеддятся разными моделями
Если индекс построен одной embedding-моделью, а запросы кодируются другой, близость векторов становится некорректной. При смене embedding-модели индекс нужно пересоздать.
5. Нет ответа «в контексте нет информации»
Без явного fallback модель часто отвечает по общим знаниям. В RAG это опасно: пользователь думает, что ответ основан на документах, хотя в документах его нет.
6. Не выводятся источники
Ответ без источников трудно проверить. Минимум сохраняйте source в metadata и показывайте список retrieved chunks в логах или интерфейсе.
7. Prompt injection из документов
В документе может быть текст: «игнорируй предыдущие инструкции». Для LLM это выглядит как часть контекста. Промпт должен отделять данные от инструкций, а production-система должна валидировать ответы.
8. Считать RAG заменой базы данных
RAG хорош для семантического поиска по тексту, но не заменяет точные SQL-запросы, транзакции, права доступа и аналитические отчёты. Для чисел и строгих фильтров используйте структурированные запросы или гибридный подход.
9. Индекс не обновляется
Документы меняются, а векторная база остаётся старой. Нужен процесс re-index: кто, когда и какие документы переиндексирует.
10. Нет оценки качества
«Мне нравится ответ» — слабая метрика. Проверяйте top-k retrieval, наличие правильного источника, корректность fallback и качество финального ответа.