Packaging & Context Handling

Материал из Systems analysis wiki
Перейти к навигации Перейти к поиску

Packaging & Context Handling — совокупность приёмов отбора, сжатия, раскладки и подачи извлечённых фрагментов знаний в контекст LLM в составе Retrieval‑Augmented Generation (RAG). Цель — максимизировать полезность ограниченного токен‑бюджета, повысить точность и устойчивость ответов и обеспечить трассируемое цитирование источников. Под «упаковкой» понимается не только формирование списка фрагментов, но и их компрессия, порядок, группировка и инструкции модели, включая стратегии stuff, map‑reduce, refine и tree‑of‑chunks.[1][2]

Определение и мотивация

В RAG‑системах качество конечного ответа определяется не только ретривом, но и тем, как отобранные фрагменты попадают в промпт. Ограничения контекста и стоимость токенов заставляют балансировать между полнотой и точностью: лишние фрагменты повышают риск «потеряться в середине» (lost‑in‑the‑middle) и удлиняют латентность, а агрессивная фильтрация/компрессия может удалить ключевые доказательства.[3] В классическом RAG источники служат внешней «непараметрической памятью», обеспечивая актуальность и цитируемость, если упаковка позволяет LLM надёжно оперировать фактами и ссылками.[1]

Чанкование и извлечение контента

Политика сегментации (chunking) определяет размер/перекрытие чанков, нормализацию и гранулярность (document→passage→sentence). Типовые подходы:

  • Правило фиксированного размера (по символам/токенам) с перекрытием для сохранения связности между чанками;[4][5]
  • Семантическое чанкование (границы по близости эмбеддингов), уменьшающее «разрывы смысла».[6]
  • Sentence‑window retrieval — изначально индексируются предложения; при ретриве извлекаются релевантные предложения с окном соседних предложений до/после для восстановления локального контекста.[7]
  • Passage‑level индексация — разбиение Википедии на ~100‑словные пассажи стало стандартом в открытом QA (DPR), что отражает пользу мелкой гранулярности для первых стадий.[8]
  • Нормализация и очистка (удаление мусора, заголовков/футеров, унификация пробелов), трекинг исходников/страниц/смещений на уровне метаданных для трассировки.[9]
  • Дедупликация кандидатных чанков (точные и near‑duplicate): шинглы + MinHash/LSH для уменьшения повторов.[10]

Диверсификация и отбор (MMR и др.)

При формировании набора контекста требуется высокая релевантность и низкая избыточность. Классическая функция Maximal Marginal Relevance выбирает следующий фрагмент с учётом близости к запросу и наибольшему сходству с уже выбранными (штраф за дубликаты):


MMR(di)=arg⁡maxdi∈D∖S[λ⋅sim(q,di)−(1−λ)⋅maxdj∈Ssim(di,dj)],λ∈[0,1].[11]

Комбинирование сигналов: гибридный ретрив (BM25 + dense) → фьюжн (например, Reciprocal Rank Fusion, RRF) → переранжирование кросс‑энкодером/ColBERT:

  • RRF: простая и эффективная несупервизорная схема слияния ранжировок разнородных ретриверов.[12]
  • Кросс‑энкодерные реранкеры (BERT/MonoT5/совр. коммерческие API) значительно повышают точность топ‑k, но добавляют латентность.[13][14]
  • Мультивекторный ретривер ColBERT (late interaction) часто служит эффективным реранкером/ретривером первого уровня на больших корпусах.[15]
  • Гибридный поиск (BM25F+вектор) реализован в промышленных движках и библиотеках с настраиваемым весом/фьюжном (альфа, RRF и т. п.).[16][17]

Компрессия контекста

Сокращение объёма контекста без потери фактов критично для стоимости и латентности:

  • Экстрактивная компрессия (извлечение ключевых предложений/фраз); абстрактивная суммаризация (перефразирование/сжатие). Классическая перспектива — Nenkova & McKeown.[18]
  • Query‑guided / instruction‑guided сжатие: суммирование под запрос/задачу (выделение доказательств и удаления нерелевантного).
  • Prompt/context compression средствами LLM‑фильтрации/прюнинга токенов (напр., LLMLingua/LLMLingua‑2) уменьшает токен‑бюджет при малой потере качества, но требует аккуратной валидации faithfulness.[19]
  • Компрессия — это компромисс качество↔стоимость↔латентность: агрессивное сжатие повышает риск пропуска нюансов/предпосылок и ухудшает атрибуцию фактов.[20]

Стратегии упаковки (stuff/map‑reduce/refine/tree)

Ниже — четыре базовые схемы раскладки источников в промпте и типовые сценарии их применения (см. также таблицу сравнения).

Stuff (прямая подача)
Склеить выбранные фрагменты (после возможной компрессии) и подать их целиком. Просто и быстро, но ограничено объёмом и подвержено lost‑in‑the‑middle на длинном вводе.[2]
Map‑Reduce
На этапе map локально ответить/суммировать по каждому фрагменту/документу, затем reduce агрегирует (сравнение, голосование, слияние). Хорошо масштабируется по числу источников, снижая нагрузку на единичный промпт; риск потери перекрёстных связей между источниками при наивной агрегации.[2][21]
Refine
Последовательное улучшение: начальный ответ по первому фрагменту, затем итеративное refine с учётом следующего фрагмента (добавление/исправление). Удобно, когда важен порядок источников; риск «залипнуть» на ранних ошибках и накопить искажения.[22]
Tree‑of‑chunks
Иерархическое сжатие/сводка: локальные резюме по чанкам → свёртки на уровне разделов → итоговая сводка. Полезно для длинных документов; требует аккуратной передачи идентификаторов источников между уровнями для корректной атрибуции.[23]
Сравнение стратегий упаковки
Стратегия Идея Стоимость/латентность Риск потери контекста Когда применять Источники
Stuff Все фрагменты сразу в один промпт Низкая (до лимита контекста) Высокий на длинных вводах (lost‑in‑the‑middle) Небольшой объём, простые вопросы [2][3]
Map‑Reduce Локальные ответы → агрегация Средняя/высокая (много вызовов) Средний (зависит от качества reduce) Много источников, нужна масштабируемость [2][21]
Refine Последовательное улучшение ответа Средняя Зависимость от порядка, риск закрепления ошибок Когда важен порядок/эволюция ответа [22]
Tree‑of‑chunks Иерархические сводки Средняя/высокая Потеря деталей на верхних уровнях Длинные документы/сборники [23]

Порядок и позиционирование источников

LLM хуже используют сведения из середины длинного контекста; полезные факты лучше располагать в начале/конце, группировать по темам/источникам и маркировать заголовками и ID. Переранжирование с учётом query‑aware важности и диверсификации помогает выносить ключевые фрагменты ближе к началу.[3][13]

Интеграция в пайплайн RAG (fusion → rerank → packaging)

Типичный многостадийный конвейер: hybrid retrieval (BM25 + dense) → fusion (RRF/взвешенная смесь) → rerank (Cross‑Encoder/ColBERT) → packaging (одна из стратегий) → генерация + цитирование. Гибридный поиск и RRF устойчивы к несопоставимости скорингов разных ретриверов; кросс‑энкодер повышает прецизионность входа в LLM, экономя токены.[16][12][14][15]

Оценка качества и абляции

Оценивание проводят на уровнях ретрива, упаковки и генерации:

  • Ретрив: Recall@k, nDCG@k, MRR — стандартные метрики ИП.[24]
  • Faithfulness/groundedness: доля утверждений, поддержанных цитатами; автоматические фреймворки (RAGAS, TruLens) + ручная валидация атрибуции.[25][26][27]
  • End‑to‑end QA: EM/F1/ROUGE в зависимости от задачи/датасета (NQ/HotpotQA и т. д.).[1]
  • Эффективность: latency p50/p95, число токенов, $‑стоимость; сравнение стратегий упаковки и уровней компрессии по качество↔стоимость.
  • Абляции: отключение MMR/дедупликации/компрессии/изменение порядка для измерения вклада каждого компонента (по состоянию на 2025‑09‑10 практика RAG‑исследований рекомендует отчётливо фиксировать k, λ, размеры чанков и лимиты токенов).[28]

Практические рекомендации и чек‑лист

  • k и диверсификация: начинайте с k=20–40 кандидатов из гибридного ретрива; применяйте MMR с \lambda≈0.5–0.8; жёстко штрафуйте дубликаты по URL/ID/хешу текста.[11][16]
  • Чанкование: 200–400 токенов с 10–20% overlap при фиксированном чанковании; для юридико‑технических документов чаще помогает sentence/window схема.[4][7]
  • Компрессия: используйте экстрактивную фильтрацию по запросу и осторожную абстракцию; LLMLingua‑подобные методы снижайте/повышайте в зависимости от faithfulness на ваших данных (обязательно A/B‑валидация).[19][27]
  • Порядок: важные/высокоуверенные фрагменты — в начале промпта; группируйте по источникам/темам, явно помечайте ID и заголовки; учитывайте эффект lost‑in‑the‑middle (дублирование ключевого факта в начале и конце может помочь).[3]
  • Реранк: если разрешает бюджет, добавляйте Cross‑Encoder/ColBERT на топ‑k (k≈50–200) перед упаковкой — это экономит токены генерации и повышает точность.[13][15]
  • Fallback‑стратегии: (1) нехватка фактов → запрос дополнительных источников; (2) превышение лимита токенов → переключение stuff→refine или включение компрессии; (3) низкая уверенность/противоречия → ответ‑отказ с явным списком недостающих ID (см. шаблон ниже).

Псевдокод конвейера упаковки

# Input: query q
cands = retrieve(q, K_sparse, K_dense)          # поиск BM25, DPR etc.
cands = diversify_MMR(cands, lambda=0.7)        # диверсификация (MMR)
snips = compress(query=q, items=cands, mode="extractive|abstractive", budget=tokens)
pkg   = package(snips, strategy="stuff|map_reduce|refine|tree")
resp  = generate(prompt=build_prompt(q, pkg), citations=True)  # LLM с цитатами

Скелет prompt‑шаблона (фрагмент)

[ЗАПРОС ПОЛЬЗОВАТЕЛЯ]
{q}

[ИСТОЧНИКИ]
{# Каждый фрагмент с ID, названием и ссылкой #}
- [{id}] {title} — {url}
{content_snippet}

[ТРЕБОВАНИЯ]
1) Используй только факты из источников, ссылайся на [ID].
2) Если данных недостаточно, скажи об этом и попроси уточнения/доп.источники.
3) Сохраняй структуру ответа и укажи список использованных [ID].


Ограничения и открытые вопросы

  • Галлюцинации и агрегация в map‑reduce/refine: абстрактивные сводки могут вводить новые факты; критичны чёткие инструкции об атрибуции и механизмы проверки цитат.[20][27]
  • Потеря деталей при агрессивной компрессии/иерархическом сжатии; важно хранить обратные ссылки до первоисточника/страницы/смещения.
  • Доменная переносимость ретриверов/реранкеров и компрессоров; требуется адаптация/тонкая настройка на доменных корпусах.[28]
  • Приватность/PII и меморизация LLM: при генерации без строгого grounding возможна утечка приватных строк; применяйте фильтры, приватные хранилища и политику отказа.[29][30]
  • Тренируемые «упаковщики», адаптивный порядок/раскладка, RLHF/feedback‑петли для повышения faithfulness, мультиязычный и сверхдлинный контекст — активные направления исследований.[28][3]

Ссылки

  • LangChain: Summarization (stuff/map_reduce/refine). [29]
  • LangChain: Text splitters. [30]
  • LlamaIndex: Response Synthesizers (refine/tree). [31]
  • LlamaIndex: Node Parsers / SentenceSplitter / SemanticSplitter. [32]
  • Haystack: SentenceWindowRetriever. [33]
  • Haystack: PreProcessors / DocumentSplitter. [34]
  • Weaviate: Hybrid search. [35]
  • Pinecone: Hybrid search. [36]
  • Cohere: Rerank API. [37]
  • RAGAS (repo/docs). [38] [39]
  • TruLens (docs). [40]

Литература

  • Manning, C. D., Raghavan, P., Schütze, H. (2008). Introduction to Information Retrieval. Cambridge University Press. ISBN 978‑0521865715.
  • Nenkova, A., McKeown, K. (2011). Automatic Summarization. FnT IR, 5(2–3), 103–233. DOI:10.1561/1500000015.
  • Lewis, P., et al. (2020). Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks. NeurIPS. arXiv:2005.11401.
  • Khattab, O., Zaharia, M. (2020). ColBERT. SIGIR’20. DOI:10.1145/3397271.3401075.
  • Izacard, G., Grave, E. (2021). Fusion‑in‑Decoder. EACL. arXiv:2007.01282.
  • Ji, Z., et al. (2023). Survey of Hallucination in NLG. ACM CS. DOI:10.1145/3571730.
  • Gao, S., et al. (2024). RAG for LLM: A Survey. arXiv:2312.10997.

Примечания

  1. ↑ 1,0 1,1 1,2 Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., et al. (2020). Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks. NeurIPS. arXiv:2005.11401. [1]
  2. ↑ 2,0 2,1 2,2 2,3 2,4 LangChain Docs. Summarization (stuff/map_reduce/refine/map_rerank). (доступ: 2025‑09‑10). [2]
  3. ↑ 3,0 3,1 3,2 3,3 3,4 Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. TACL. arXiv:2307.03172. [3]
  4. ↑ 4,0 4,1 LangChain Docs. Text splitters (RecursiveCharacter/TokenTextSplitter). (доступ: 2025‑09‑10). [4]
  5. ↑ LlamaIndex Docs. SentenceSplitter / TokenTextSplitter / SemanticSplitter. (доступ: 2025‑09‑10). [5] [6] [7]
  6. ↑ LlamaIndex Docs. SemanticSplitterNodeParser. (доступ: 2025‑09‑10). [8]
  7. ↑ 7,0 7,1 Haystack Docs. SentenceWindowRetriever. (доступ: 2025‑09‑10). [9]
  8. ↑ Karpukhin, V., Oguz, B., Min, S., Lewis, P., Wu, L., Edunov, S., Chen, D., Yih, W.‑T. (2020). Dense Passage Retrieval for Open‑Domain Question Answering. EMNLP. arXiv:2004.04906. [10]
  9. ↑ Haystack Docs. PreProcessors / DocumentSplitter. (доступ: 2025‑09‑10). [11] [12]
  10. ↑ Broder, A. Z. (1997). On the Resemblance and Containment of Documents. Compression and Complexity of Sequences. [13]
  11. ↑ 11,0 11,1 Carbonell, J., Goldstein, J. (1998). The Use of MMR, Diversity‑Based Reranking for Reordering Documents and Producing Summaries. SIGIR’98, pp. 335–336. DOI:10.1145/290941.291025.
  12. ↑ 12,0 12,1 Cormack, G. V., Clarke, C. L. A., Büttcher, S. (2009). Reciprocal Rank Fusion outperforms Condorcet and Individual Rank Learning Methods. SIGIR’09, pp. 758–759. DOI:10.1145/1571941.1572114. [14]
  13. ↑ 13,0 13,1 13,2 Nogueira, R., Cho, K. (2019). Passage Re‑ranking with BERT. arXiv:1901.04085. [15]
  14. ↑ 14,0 14,1 Cohere Docs. Rerank API overview. (доступ: 2025‑09‑10). [16]
  15. ↑ 15,0 15,1 15,2 Khattab, O., Zaharia, M. (2020). ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT. SIGIR’20, pp. 39–48. DOI:10.1145/3397271.3401075. arXiv:2004.12832.
  16. ↑ 16,0 16,1 16,2 Weaviate Docs. Hybrid search (BM25F + vector). (доступ: 2025‑09‑10). [17]
  17. ↑ Pinecone Docs. Hybrid search. (доступ: 2025‑09‑10). [18]
  18. ↑ Nenkova, A., McKeown, K. (2011). Automatic Summarization. Foundations and Trends in Information Retrieval, 5(2–3), 103–233. DOI:10.1561/1500000015.
  19. ↑ 19,0 19,1 Zhu, Y., Shao, Z., Li, M., et al. (2023). LLMLingua: Compressing Prompts for Accelerating LLM Inference. arXiv:2310.05736. [19]
  20. ↑ 20,0 20,1 Ji, Z., Lee, N., Frieske, R., et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12), Art.248. DOI:10.1145/3571730.
  21. ↑ 21,0 21,1 Izacard, G., Grave, E. (2021). Leveraging Passage Retrieval with Generative Models for Open‑Domain QA (Fusion‑in‑Decoder). EACL. arXiv:2007.01282. [20]
  22. ↑ 22,0 22,1 LlamaIndex Docs. Response Synthesizers: refine. (доступ: 2025‑09‑10). [21]
  23. ↑ 23,0 23,1 LlamaIndex Docs. Tree Summarize. (доступ: 2025‑09‑10). [22]
  24. ↑ Manning, C. D., Raghavan, P., Schütze, H. (2008). Introduction to Information Retrieval. Cambridge Univ. Press. (см. главы о nDCG/MRR). [23]
  25. ↑ Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval‑Augmented Generation. arXiv:2309.15217. [24]
  26. ↑ TruLens Docs. Evaluating RAG (groundedness, relevance). (доступ: 2025‑09‑10). [25]
  27. ↑ 27,0 27,1 27,2 Rashkin, H., Nakov, P., et al. (2023). Measuring Attribution in Natural Language Generation. Computational Linguistics, 49(4), 1207–1261. DOI:10.1162/coli_a_00486.
  28. ↑ 28,0 28,1 28,2 Gao, S., et al. (2024). Retrieval‑Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997. [26]
  29. ↑ Carlini, N., Tramèr, F., et al. (2021). Extracting Training Data from Large Language Models. USENIX Security. [27]
  30. ↑ Shokri, R., Stronati, M., Song, C., Shmatikov, V. (2017). Membership Inference Attacks Against ML Models. IEEE S&P. [28]
Источник — https://systems-analysis.ru/wiki/index.php?title=Packaging_%26_Context_Handling&oldid=2857