Типичные проблемы и потеря в середине

Каталог граблей RAG: где он чаще всего ломается и как это распознать.

Большинство провалов RAG — не в LLM, а в извлечении: плохие чанки, нерелевантный контекст и неудачное расположение фактов в промпте.

Проблема 1. Плохой чанкинг

Слишком крупные чанки размывают вектор и тащат лишнее; слишком мелкие рвут факт на части. Симптом: поиск находит «около темы», но не сам ответ. Лечение — подбор размера и стратегии чанкинга, overlap, нарезка по смыслу.

Проблема 2. Нерелевантный контекст

В top-k просочились чанки не по теме. Они отвлекают модель и провоцируют ошибки. Лечение: реранкинг, гибридный поиск, фильтры по метаданным, аккуратный выбор k.

Проблема 3. Потеря в середине (lost in the middle)

Исследования показали: LLM лучше всего использует информацию в начале и в конце контекста, а то, что в середине длинного промпта, часто «не замечает». Если нужный чанк оказался посередине большого контекста, ответ может его проигнорировать.

Практический вывод: не вали в промпт двадцать чанков. Лучше реранкингом отобрать немного самых релевантных и поставить лучшие по краям. Покажем такую перестановку.

ranked = ["chunkA", "chunkB", "chunkC", "chunkD", "chunkE"]  # по убыванию релевантности

def reorder_edges(chunks):
    # лучшие — по краям, слабые — в середину (борьба с lost-in-the-middle)
    head, tail = [], []
    for i, c in enumerate(chunks):
        (head if i % 2 == 0 else tail).append(c)
    return head + tail[::-1]

print("Было:  ", ranked)
print("Стало: ", reorder_edges(ranked))

Вывод:

Было:   ['chunkA', 'chunkB', 'chunkC', 'chunkD', 'chunkE']
Стало:  ['chunkA', 'chunkC', 'chunkE', 'chunkD', 'chunkB']

Самый релевантный chunkA остался в начале, второй по силе chunkB — в самом конце, а слабые ушли в середину, где «теряются» не так критично.

Проблема 4. Несоответствие вопроса и документов

Пользователь пишет коротко и разговорно («чё с возвратом?»), а документы — формально. Эмбеддинги частично сглаживают это, но сильный разрыв стиля вредит. Лечение — query rewriting (следующий урок).

Шпаргалка симптом → причина

СимптомВероятная причина
ответ «около темы»плохой чанкинг
модель цитирует не тонерелевантный контекст / нет реранкинга
факт был в контексте, но проигнорированlost in the middle
совсем не находитнизкий recall, разрыв стиля запроса

Итог

  • Чаще всего виноват retrieval, а не LLM.
  • «Потеря в середине»: середину длинного контекста модель использует хуже краёв.
  • Меньше, но релевантнее чанков и сильнейшие — по краям.
Проверьте себя
1. Что такое эффект «потеря в середине» (lost in the middle)?
AБД теряет данные
BLLM хуже использует информацию в середине длинного контекста, чем по краям
CЧанки удаляются случайно
DЭмбеддинги обнуляются
2. Где чаще всего кроется причина плохих ответов RAG?
AВ самой LLM
BВ извлечении: плохой чанкинг или нерелевантный контекст
CВ цвете интерфейса
DВ версии Python
3. Практический вывод из «lost in the middle»?
AКласть как можно больше чанков
BБрать меньше, но релевантнее чанков и ставить лучшие по краям
CВсегда ставить нужный чанк в середину
DОтключить реранкинг
Поддержать проект