Почему RAG — это не просто «добавить поиск»: latency, качество и выбор стратегии retrieval

[Ariless]

Интересный разрез про latency и chunking. В RAG есть более базовый слой - это наблюдаемость retrieval. На практике ключевая проблема не в том, "что вернул поиск", а в том, какой именно контекст оказался в prompt на конкретном шаге. При эвристическом ранжировании это часто неочевидно и плохо воспроизводимо.

В одном RAG-пайплайне тест падал с 422 и первопричина оказалась в retrieval-слое: релевантный контекст не попадал в LLM из-за логики матчинг/скоринга. На уровне симптомов это выглядело как ошибка модели, но LLM просто работал с некорректным входом. После изоляции retrieval через mock-режим стало видно, что проблема находится до генерации.

В этом смысле top-k, chunk size и retrieval strategy - это не только параметры качества и latency, а границы наблюдаемости: они определяют, можно ли вообще восстановить и зафиксировать вход системы в момент ответа.

[Anton_Trofimov]

Да, согласен. Это как раз следующий уровень после измерения latency и качества ответа: нужно уметь восстановить и понять, какой именно context попал в prompt на конкретном запросе.

В статье я больше фокусировался на влиянии top-k, chunk size и retrieval mode на размер prompt, latency и качество ответа. Но с практической точки зрения эти параметры действительно важны и для наблюдаемости: без логирования retrieved units, assembled prompt, score/ranking и режима retrieval сложно понять, проблема возникла в модели или раньше.

Ваш пример с mock-режимом хорошо показывает эту границу: если LLM получает некорректный вход, симптом может выглядеть как ошибка генерации, хотя первопричина находится на этапе retrieval.