RAG на практике: где реально растёт задержка и как выбирать стратегию поиска

На локальном стенде с GPU RTX 3090 Ti, моделью Mistral 7b и векторным хранилищем Chroma автор провёл серию экспериментов, чтобы понять, где именно RAG-система становится дороже обычного запроса к языковой модели. Корпус документов включал текстовые файлы про retrieval, embeddings, latency и выдержки из публичной документации Chroma и Ollama. Embedding строила модель qwen3-embedding:0.6b.

RAG (Retrieval-Augmented Generation) — подход, при котором языковая модель перед генерацией ответа получает релевантные фрагменты из внешней базы знаний. Идея проста: модель не обязана помнить всё, достаточно найти нужное и передать в контекст. На практике это означает дополнительный операционный слой: поиск по векторной базе, сборку prompt из найденных фрагментов и их обработку моделью. Каждый из этих шагов влияет на задержку, стоимость запроса и итоговое качество ответа.

Результат первого же сравнения запросов с RAG и без него оказался показательным: сам поиск через Chroma был быстрым и не стал узким местом. Основная дополнительная нагрузка появилась в трёх местах — построение embedding для запроса, увеличение assembled prompt и рост числа input tokens, которые затем обрабатывает модель. Иными словами, RAG может быть дорогим не потому что поиск медленный, а потому что найденный контекст раздувает входной prompt. Даже быстрый vector search приводит к росту TTFT (time to first token) и prompt eval duration.

Параметр top-k — количество извлекаемых фрагментов — оказался одним из ключевых рычагов управления нагрузкой. Распространённая интуиция «взять больше chunks на всякий случай» не подтвердилась. При росте top-k с 1 до 10 количество input tokens выросло примерно с 522 до 3881. Сам поиск оставался быстрым, но нагрузка на обработку prompt росла почти линейно. При этом качество ответов линейно не улучшалось: top-k=1 иногда был слишком узким, top-k=10 давал больше шума без стабильного прироста точности. Рабочий диапазон в данном эксперименте — top-k от 3 до 5, с осторожным допуском до 7. Автор делает вывод, что top-k — это параметр проектирования системы, а не техническая настройка по умолчанию: его нужно выбирать исходя из баланса между полезностью ответа, задержкой, стоимостью и допустимым уровнем лишнего контекста.

Аналогичная история с chunk size — размером фрагмента, на которые нарезаются документы перед индексацией. Проверялись размеры 500, 1000, 1500 и 2500 символов. Диапазон 500–1000 символов дал наиболее устойчивое качество при низком уровне context noise. Фрагменты по 1500 символов иногда оставались полезными, но давали нестабильность. Фрагменты по 2500 символов выглядели как тяжёлая верхняя точка: больше payload, выше TTFT, выше prompt eval duration, больше шума и периодические ошибки в ответах. Chunk size определяет, какую единицу знания увидит retrieval и сколько лишнего текста попадёт в prompt — это решение принимается на этапе подготовки данных и напрямую влияет на поведение всей системы.

Отдельный вывод касается оценки качества: она оказалась чувствительной к соответствию вопросов содержанию корпуса. Часть знаний в корпусе пересекалась с тем, что модель знала сама, поэтому первый прогон дал неоднозначную картину — RAG где-то помогал, где-то был нейтрален, а где-то ухудшал практическую полезность ответа. После уточнения набора вопросов под содержание документов RAG стал чаще давать более обоснованные ответы, а модель без retrieval чаще ошибалась на специфичных терминах и деталях. При этом выводы по задержке и overhead остались неизменными — они оказались устойчивыми независимо от качества корпуса.

Общий вывод эксперимента: retrieval нужно оценивать как компромисс между практической пользой и дополнительной нагрузкой на систему. Если найденный контекст исправляет ошибку модели или добавляет факты из внешней базы знаний — дополнительная стоимость оправдана. Если retrieval возвращает контекст, который модель и так знает, или вытаскивает нерелевантный шум, система становится тяжелее без сопоставимой пользы. Стратегию поиска нужно выбирать под тип вопроса, структуру данных, latency budget и требования к качеству.