大模型面经：RAG与Long context“相爱相杀”背景下，如何设计最优解决方案？ 原创

本篇分享RAG与long context结合的实践方案。

本篇始于一个老生常谈的话题，“一旦大模型的Context Length变大，RAG还有没有存活的必要？”

RAG主要通过问题从知识库中找相关答案，然后把检索到的内容再用大模型总结；Long context相当于把全部文本内容输入给大模型，利用大模型查找或总结。

这两者评估的维度包括成本、是否使模型变得更智能、是否可以混合检索和推理、是否可以缓存、推理时间等等。

其实两者之争也相当于左右手之争，最近在工作场景中遇到越来越多两者不同的场景，本篇就来分享一下目前是如何结合两种方法。

下面是一个具体示例。

目前有5M token量级的私有化医疗知识库，需要搭建智能问诊系统，如何巧妙结合RAG与Long context设计你的最优方案？

1. 思路

首先来梳理一下需求：医疗场景对准确性要求非常高，另外知识更新频繁，并且需要处理病史、检查报告等长文本。

那么现在来分析一下这两种技术起到的作用：

• RAG优势：可以精准定位最新知识，降低幻觉风险
• Long context优势：可以结合推理理解复杂症状关联，处理多轮对话上下文

另外基于现状进行分析，首先如果只用LLM，5M token的文档全量输入LLM从哪个角度考虑都是不现实的，成本高，性能还差；如果单纯使用RAG又可能遗漏跨文档关联推理。

2. 方案

首先设计一个动态路由层，主要需要做三件事，包括相关文档查找，潜在文档关联以及深度语义关联。

第一层：相关文档查找

基于轻量级Embedding模型快速检索，筛选Top5相关文档，这里还有一些显得比较专业的trick，比如Embedding模型是如何选择的？BAAI or bge-small？是否合理？有没有做query rewriting？等等。

第二层：潜在文档关联

可以构建文档关系图谱，通过Graph RAG识别潜在关联文档；也可以自建一个知识图谱架构进行识别。

第三层：深度语义关联

对精选的3-5份文档使用Long context窗口进行深度语义关联分析。

另外建立缓存也是必须的，缓存优化策略包括直接建立症状-诊断pair的向量缓存库，长尾查询，动态模型切换等等。

更精细的调整还包括：

• 渐进式的上下文注入：首次响应的时候使用RAG精准片段和关键元数据，在追问阶段采用滑动窗口机制（不无限制增加上下文，需要保留最相关的部分），逐步注入关联文档的全文。
• 多重验证：使用输出结果反向检索知识库，进行实时校验；后期构建诊断逻辑链的可视化追溯校验。

从上面的步骤基本可以完成整个方案的设计，如果更细节的话面试官可能会让写一个动态路由的代码，下面是一个示例

class MedicalReasoner:
    def __init__(self):
        self.retriever = HybridRetriever(knowledge_graph)  # 结合向量+图检索
        self.llm = MedPaLM(chunk_size=8192)  # 定制医疗长文本处理模型
    def diagnose(self, query):
        # 阶段1：精准检索
        base_docs = self.retriever.search(query)  
        # 阶段2：上下文增强
        extended_context = self._expand_context(base_docs)  
        # 阶段3：长文本推理
        return self.llm.generate(
            prompt=build_prompt(query, extended_context),
            max_tokens=2048
        )

最后如果还需要更深度的表达，还有一些细节内容可以去润色，比如：

建立快速检索的过程中，用fasis进行索引还是自研了召回机制，采用了什么压缩策略？如何评估召回好不好？有没有对RAG prompt进行优化，进行引导式摘要、多段拼接、answer-aware检索等等...  

文转载自公众号瓦力算法学研所，作者：喜欢瓦力的卷卷

原文链接：​​https://mp.weixin.qq.com/s/LLipYnSBWC-I0dC_ZZS3UA​​