инструменты 1 мин

Проблема вашего RAG не в векторной базе. Она в том, что вы решили до неё

Автор год строил retrieval-систему для AI-агентов и обнаружил, что качество определяют не выбор векторной БД или эмбеддинг-модели, а ранние архитектурные решения: размер чанков, способ извлечения данных, последовательность выбора компонентов. Многие из этих решений принимаются «по умолчанию» из туториалов и оказываются неоптимальными.

Практический опыт показывает, что типовые туториалы по RAG закладывают неоптимальные defaults. Разработчикам RAG-систем стоит прочитать, чтобы понять, какие решения принимать первыми и как валидировать их на собственном корпусе, а не слепо следовать best practices.

Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.

О чём статья

  • Переход от чанков размером «страница» к чанкам «секция документа» сократил количество вызовов агента с ~6 до 1 на запрос
  • Гибридный поиск (keyword + semantic), который был лучшим на уровне страниц, при переходе к секциям ухудшил MRR с 0.93 до 0.63 — чистый BM25 стал точнее
  • Решения в RAG-пайплайне взаимозависимы: изменение гранулярности чанков требует пересмотра алгоритма ранжирования, бенчмарки нужно перезапускать
  • Реальные проблемы качества RAG лежат не в выборе компонентов, а в последовательности решений: сначала определить единицу извлечения, потом способ ранжирования
Юлия Тарасова Medium #llm
Читать оригинал

Ещё по теме

Комментарии