Проблема вашего RAG не в векторной базе. Она в том, что вы решили до неё
Автор год строил retrieval-систему для AI-агентов и обнаружил, что качество определяют не выбор векторной БД или эмбеддинг-модели, а ранние архитектурные решения: размер чанков, способ извлечения данных, последовательность выбора компонентов. Многие из этих решений принимаются «по умолчанию» из туториалов и оказываются неоптимальными.
Практический опыт показывает, что типовые туториалы по RAG закладывают неоптимальные defaults. Разработчикам RAG-систем стоит прочитать, чтобы понять, какие решения принимать первыми и как валидировать их на собственном корпусе, а не слепо следовать best practices.
Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.
О чём статья
- Переход от чанков размером «страница» к чанкам «секция документа» сократил количество вызовов агента с ~6 до 1 на запрос
- Гибридный поиск (keyword + semantic), который был лучшим на уровне страниц, при переходе к секциям ухудшил MRR с 0.93 до 0.63 — чистый BM25 стал точнее
- Решения в RAG-пайплайне взаимозависимы: изменение гранулярности чанков требует пересмотра алгоритма ранжирования, бенчмарки нужно перезапускать
- Реальные проблемы качества RAG лежат не в выборе компонентов, а в последовательности решений: сначала определить единицу извлечения, потом способ ранжирования
Юлия Тарасова
Medium #llm
Читать оригинал
Комментарии