企业官网建设流程全解析

最近在做多模态检索增强生成的项目，遇到一个特别典型的场景：视觉检索返回的图文片段又碎又散，相关的内容七零八落，直接拼给大模型，效果一言难尽。后来看到这个方向——“Navigating Sparse Evidence: Agentic Visual RAG via Explicit Context Selection and Consolidation”，标题几乎精准命中我踩过的所有坑。它解决的核心问题是：当视觉检索证据稀疏、零散、相关信号不连续时，如何让RAG系统通过“显式上下文选择+整合”而不是“无脑拼接”，稳定产出高质量答案。

这篇博文我会从问题拆解、方案结构、核心实现、排查技巧几个角度展开，涉及的关键环节都会配上可落地的伪代码和参数经验。适合正在做多模态RAG、视觉问答、知识库问答的算法工程师和研究人员，也适合想理解“Agentic RAG到底比普通RAG强在哪”的产品和技术同学。内容会围绕视觉场景展开，但选择和整合的核心理念放到纯文本RAG里同样适用。

1. “稀疏证据”到底难在哪？先把痛点拆干净

1.1 从一次让人抓狂的图文问答说起

想象这样一个任务：用户给出一张图，问“图中产品的保修期是多久？报修流程的第一步是什么？”你预先建好的知识库来自一份多页产品手册，里面有大量图片、表格、说明文字，位置分散在不同页面。检索系统基于图文混排的片段召回，返回了top-30个候选片段，但你打开一看：真正和问题相关的可能只有5个，其余全是“看似相关实则无关”的内容，比如同款产品的其他型号参数、维护注意事项、常见故障码。

传统RAG的做法是把这30个片段按相似度排序，取前5到10个一股脑塞进上下文。结果就是：模型被大量噪声干扰，开始一本正经地胡说八道，甚至把A型号的保修期套在B型号上。我在多个开源VQA数据集上复现过这种翻车，问题几乎都集中在“相关证据被淹没在无关片段里”，而不是“模型理解能力不足”。

这就是“稀疏证据”的典型含义：不是没有证据，而是证据密度极低、分布极其零散，传统基于向量相似度的“直筒式”方案根本扛不住。

1.2 “证据稀疏”其实包含三个层次

第一个层次是片段层面稀疏。视觉文档切分出来的图文块往往很小——一张图配一段图注、一个表格算一块、一个页眉页脚也算一块。真正承载答案信息的片段可能只占检索结果的很小比例。第二个层次是相关性层面稀疏。因为视觉特征和文本特征存在模态鸿沟，向量召回时很容易把“版面长得像”的内容当成“语义相关”的内容，导致真实相关片段被排到很靠后的位置。第三个层次是语义连贯性层面的稀疏。答案可能跨了三个页面：第一页有产品型号，第三页有保修政策表，第五页的流程图里写了报修第一步。单独看每一页都不算“完整证据”，必须把它们合并起来才能推理出正确答案。

很多人做RAG只盯着召回率，觉得把top-k调大，相关片段总能进来。但稀疏场景下，召回率上去了，噪声也跟着上去，最终生成质量不升反降。这个矛盾是稀疏证据最让人头疼的地方。

1.3 为什么传统RAG在稀疏证据面前会“露怯”

传统RAG的流程可以概括为“检索—拼接—生成”三步。这里面的关键缺陷是两个：一是缺少“选择”环节，检索结果直接被当作上下文喂给生成模型；二是缺少“整合”环节，碎片化证据没有经过合并、去重、排序，模型拿到的是“一堆互不相干、甚至有冲突的段落”。

我举个直观例子。你把三页文档的相关片段直接拼起来给模型看，里面既有保修期“12个月”，又有“保修期以官方登记日期起算”，还混着一条“电池保修6个月”。模型怎么知道该用哪条？如果加入显式选择，系统会先判断“用户问的是整机还是电池”，再决定用哪条证据；如果加入整合，系统会把分散的“保修期”“起算日期”“适用范围”合并成一条完整的证据链，模型看到的是“整机保修12个月，自登记日起算，电池单独保修6个月”——这两种处理方式的差别是本质性的。

所以这个项目思路的第一价值，不是发明了什么新模型，而是把“选择”和“整合”两个被忽视的环节，重新拉回RAG系统设计的主流程里。

2. 为什么非得是“Agentic”？加个重排序器不行吗

2.1 单次检索的“天花板”决定了方案的边界

有人可能会问：你说的选择问题，我用一个更强大的reranker不也能解决？先给检索结果打个分、筛一遍，再喂给生成模型，效果不也能上去？

这部分对，但只对了一半。单次检索方案的瓶颈在于：检索器的查询是固定的，如果初始查询本身覆盖不足——比如用户的问题指向的是一个隐含实体，而查询里只包含显式的描述词——你再怎么rerank，召回的候选里压根没有正确答案，排序模型也只能矮子里拔将军。而且视觉场景更麻烦，初始查询的文本描述可能和文档里的图像内容差距很大，向量检索很难一次性挖出所有相关证据。

2.2 Agentic机制带来的三个真实能力

“Agentic”听起来高大上，落到实际工程里其实就是三件事：迭代式信息获取、动态停止决策、多源证据整合规划。

先看迭代式信息获取。系统第一轮检索拿到若干候选，发现“证据置信度不足”后，可以基于已获取的部分信息构造第二、第三轮查询。比如第一轮发现文档里出现了“保修政策”关键词，但没有对应表格，下一轮就专门针对表格内容做局部检索，把缺失的证据补齐。动态停止决策解决的是“该检索多少轮”的问题：如果证据已经足够支撑答案，就停止迭代，而不是机械地固定检索三轮。多源证据整合规划对应的是标题里的“Consolidation”，也就是如何把不同来源、不同模态、不同页面的证据片段组织成一条结构化的证据链。

这三件事背后有一个共同逻辑：把“检索”从一次性的动作变成“理解—判断—再行动”的闭环。这正是Agentic RAG区别于普通RAG的核心。

2.3 显式选择比隐式权重强在可解释性和可控性

标题里有个非常关键的修饰词——“Explicit Context Selection”。为什么强调“显式”？因为很多RAG方案实际上也做了选择，但选择是隐式的，体现在attention权重里、体现在融合层的加权系数里。隐式选择的问题在于：你不知道模型为什么选A不选B，出了问题也没法定向修正。

显式选择的思路是：把“哪些检索片段应该进入最终上下文”这一步从生成模型里剥离出来，变成一个可观察、可调试、可干预的独立环节。我觉得这个设计有个特别实在的价值：当线上效果出问题时，你能直接看到“选择阶段筛掉了哪条相关证据”“整合阶段把哪两条证据合并成了错误信息”，而不是对着一个黑盒模型瞎猜。这对于生产环境的调优来说几乎是刚需。

补充一点，参考常见实践，显式选择还可以通过一个打分器配合阈值实现。打分器给每个候选片段输出“是否进入最终上下文”的概率，再结合一个可配置的阈值（比如0.5到0.7之间）和预算控制，避免把所有候选都塞进上下文。这个设计给我的感受是：它不是用复杂的公式去“拟合”选择行为，而是把选择本身当成一个透明的决策过程来建模。

3. 核心实现：显式上下文选择与证据整合的关键细节

3.1 整体流程拆解：一个带决策循环的RAG框架

这套方案的整体流程，结合我自己的实现经验，可以拆成五个步骤。

第一步，初始查询构造。把用户问题和多模态输入（比如图片、文档截图）编码成统一的查询表示。第二步，迭代检索循环。Agent根据当前查询，从视觉文档库中检索候选证据片段。第三步，显式上下文选择。对每个候选片段计算上下文相关性和有用性得分，筛选出达标片段。第四步，证据整合。把筛选后的零散片段按空间位置和语义关系进行合并、去重、排序，形成高质量上下文块。第五步，答案生成。将整合后的上下文块与用户问题交给生成模型，产出最终答案。

从工程实现角度，这个框架本质上是在“检索—生成”中间插入了两个可插拔模块：选择模块和整合模块。两者均独立于检索器和生成器，可以单独优化、单独测试、单独替换。

我按常见实践补全过一个最小实现版本，实测下来最关键的几个参数分别是：选择阶段的相似度阈值、整合阶段的最大上下文长度，以及迭代检索的轮数上限。这三个参数直接决定系统在“证据充足”和“证据稀疏”之间的行为表现，后面会专门展开。

3.2 显式上下文选择模块：分数设计决定系统上限

显式上下文选择的核心，是一个候选证据的打分器。这里不能简单用“查询与片段的向量相似度”一个分数来决定，因为视觉RAG里，一个片段的相关性需要综合多路信号。

我使用的最简有效打分器包含四路信号：第一路是与查询的语义相似度，这个不用说，是基础相关性信号；第二路是与已选证据的互补度，避免选出一堆说同一件事的重复片段；第三路是跨模态的对齐分数，比如图像片段与周围文本描述的一致性；第四路是位置先验，视觉文档中中间主体区域的证据通常比页眉页脚的证据更可靠。

考虑到需要直观展示，下面给出一段可运行的PyTorch风格伪代码，方便你快速搭一个最小版本：

def compute_evidence_score(query_feat, page_feat, region_feat, ocr_feat, selected_evidence_feats, region_bbox, page_size): score = 0.0 # 信号1：与查询的语义相关性，权重0.4 score += 0.4 * cosine_similarity(query_feat, region_feat) # 信号2：与已选证据的互补度，权重0.3 # 计算与当前所有已选证据的最大相似度，取1减得到“信息增量” if len(selected_evidence_feats) > 0: max_sim = max([cosine_similarity(region_feat, feat) for feat in selected_evidence_feats]) score += 0.3 * (1 - max_sim) else: score += 0.3 # 信号3：跨模态对齐，权重0.2 # 图像特征与对应的OCR文本特征一致性 score += 0.2 * cross_modal_alignment(region_feat, ocr_feat) # 信号4：位置先验，权重0.1 # 越靠文档主体区域的片段越可能是核心内容 score += 0.1 * position_prior(region_bbox, page_size) return score

这段伪代码展示了显式选择的核心逻辑：多个信号加权组合，等价于“多视角证据投票”。权重的选择基于一个直觉——相关性和互补度是最重要的两路信号，跨模态对齐和位置先验作为辅助信号，防止把噪声选进上下文。我实测过，把“互补度”这项去掉之后，系统容易出现证据冗余：选出的片段全是同一个知识点的不同表述，整合后信息量反而不如只选一条。

注意：权重不要照抄，需要根据你的文档类型和检索器效果调整。如果检索器本身召回精准，可以把互补度权重调低；如果召回结果碎片化严重，互补度权重应当调高。

3.3 证据整合模块：空间聚合加语义合并，两步走

整合模块的目标是把零散证据合并成“给生成模型看的干净上下文”。我实现的整合逻辑分两步：空间聚合和语义合并。

空间聚合这一步处理的是“同一区域被切成多块”的情况。视觉文档解析时会因为版面问题，把一块完整内容切成多个候选块，比如表格被切成上下两段、图注被截成两行。这时可以通过候选块的bounding box重叠度判断它们是否属于同一物理区域，用IoU阈值（经验值0.5左右）做聚类，属于同一个聚类的块直接合并，去除重复信息。

语义合并这一步处理的是“分散在不同区域但表达同一语义”的情况。空间聚合解决不了跨页的分散，需要语义层面的聚类。做法是用文本向量和图像向量的融合表示，两两计算相似度，超过阈值（经验值在0.75到0.85之间）的候选块合并成一个证据组。关键限制是合并后的上下文块总长度不能超过生成模型的上下文窗口，我一般把单次整合后的目标控制在模型窗口大小的三分之一到二分之一，给生成阶段留足空间。

def consolidate(candidates, iou_threshold=0.5, semantic_threshold=0.8, max_context_tokens=1200): # Step 1: 空间聚合，解决“同一区域被切碎”的问题 spatial_clusters = cluster_by_layout(candidates, iou_threshold) # Step 2: 语义合并，解决“跨页分散但语义一致”的问题 merged_clusters = [] for cluster in spatial_clusters: merged = merge_cluster_by_semantics(cluster, semantic_threshold) # 按语义边界切分，防止把不相干内容强行绑到一起 merged_clusters.extend(split_by_semantic_boundary(merged)) # Step 3: 按得分排序，控制总长度 ranked = rank_by_evidence_score(merged_clusters) return top_k_with_budget(ranked, max_context_tokens)

这里的核心技巧是第三步的top_k_with_budget：按“每token的增量信息量”对候选证据排序，不做一刀切，而是确保积分预算不超上限的前提下尽量多带有效证据。如果预算紧张，宁可少选几条高置信证据，也不要塞一堆“查不到直接相关”的低分内容。

3.4 实际踩过的坑：三个最容易出问题的细节

第一个坑是整段丢弃vs局部保留的问题。很多实现为了省事，选择阶段直接丢弃低分片段，但这可能误伤一段长文本里包含的寥寥几句关键信息。我在实践中改为“片段内句子级选择”：先对片段整体打分，对低分片段不直接丢弃，而是再次切分，计算其中每个句子的分数，保留高分子的子片段。这个改动在文档类视觉RAG上成功率提升明显。

第二个坑是重叠区域的重复整合。空间聚合后，两个相邻候选块之间可能还有重叠文字，合并时如果不做去重，生成模型会看到同一句话出现两遍，干扰输出。我在整合时加入了一个基于字符匹配的去重逻辑：合并前先检测重叠字符串，合并时只保留一份。

第三个坑是跨页图注和正文的对应关系。视觉文档里，“图注在上一页，图在下一页”的情况相当常见。如果整合模块只做文本相似度合并，很容易忽略图注和图像之间的跨页关联。我在实际项目中补充了一个规则：当检测到某候选块是图像区域时，把相邻页的图注文本作为补充证据，强制合并进同一证据组。这个规则相当简单，但在实际效果上帮了大忙。

4. 稀疏证据场景下的典型失败模式与排查技巧

4.1 失败模式一：关键证据被选择阶段截断

表现是：检索阶段明明召回了正确答案所在的片段，但在选择阶段该片段分数偏低，被阈值过滤掉了。排查时先确认检索召回集中是否存在正确答案的线索。如果存在但被过滤，说明打分器对“相关但表达隐晦”的证据不够敏感。我的经验是优先调整跨模态对齐信号的权重，因为这类证据通常是文字提到但图像表达不明确，OCR特征和图像特征的对齐分数偏低，把权重调低一些，同时把互补度权重调高，往往能缓解。

另外一个处理技巧是：把“是否命中查询中的实体”作为一个强先验信号加入打分器。比如查询里包含“保修期”，候选片段里出现了“保修期”三个字，就应该直接加一个较大的加分项。这种做法不优雅，但我实测下来非常有效，尤其是在工业级文档场景。

4.2 失败模式二：检索结果整体偏移

表现是：前几轮检索回来的候选片段都是同主题内容，但不是答案真正所在的区域。比如用户问“报修流程”，检索回来的都是“产品保修政策”“维护建议”，流程图始终没被召回。

这种问题靠选择模块解决不了，得回到检索模块。排查时我会先做一轮检索诊断：把检索结果按得分排序，人工看前20个片段，判断是否有“种子证据”。如果种子证据存在但排名靠后，就在检索器层面调重排序策略；如果种子证据根本不在召回集里，就需要考虑增加检索轮次，让Agent基于已获取的中转信息发起第二轮查询。在我做过的项目里，这种“两跳检索”能救回不少被漏掉的跨页证据。

4.3 失败模式三：语义合并阶段引入了幻觉

表现是：整合模块把两条本不该合并的证据合并到了一起，生成模型基于这条“错误拼装”的证据编出了文档里不存在的信息。

这是整合阶段最危险的问题。我做过一个案例分析：一条证据说“保修期为自购买日起12个月”，另一条说“电池保修期为6个月”，语义相似度计算后触发了合并阈值，模型把两条合并成“所有部件保修期为6个月”，错误结论就这么出来了。

排查时先检查语义合并的阈值，我一般建议设得保守一些，0.85以上，宁可漏合并，不可错合并。再从工程角度加一个边界检测：如果两条证据的实体集合没有交集（比如一个是“整机”，一个是“电池”），强制禁止合并。这个规则能拦截大部分跨实体错误合并。

4.4 排查速查表

提醒一点：排查Agentic RAG问题时，日志设计一定要完整。每个阶段（检索、选择、整合）的输入输出都要留痕。这类系统一旦出错，问题经常跨模块耦合，没有完整日志很难定位到底哪个环节出了错。

5. 评估设计：怎么判断系统真的“变强了”

5.1 指标不要只看最终答案正确率

只盯着最终答案的准确率评估这种系统，很容易掩盖中间环节的问题。我建议至少同时看三组指标。

第一组是证据召回率：正确答案对应的证据片段，是否被选择阶段成功纳入了最终上下文。这个指标衡量的是系统的“找证据”能力。第二组是上下文纯度：最终上下文里，真正和问题相关的片段占比多少。这个指标衡量的是“选证据”的能力，纯度低说明选择模块还有大量噪声漏进来。第三组是最终生成质量，可以用准确率、相关性和忠实度（faithfulness）来度量。

只看最终准确率有什么问题？我踩过的坑是：模型基于错误的证据也能蒙对答案，准确率看起来不错，但换一个问法就翻车。“证据召回率”和“上下文纯度”能更早反映系统有没有结构性短板。

5.2 数据集构造与评估流程

评估数据集不要只做“好检索”的简单样例，要刻意加入稀疏证据样本。我构造数据集时一般模拟三类场景：跨页证据、跨模态证据、噪声高证据。跨页证据是答案分布在多个页面；跨模态证据是答案需要图像和文字共同推理；噪声高证据是检索结果里混入大量高相似度的干扰片段。

评估流程分三步：先用离线指标对比各阶段效果；再做端到端评测，覆盖不同难度层级的样本；最后抽出失败案例做定向分析。这套流程走下来，系统的迭代速度会比自己“凭感觉调参”快很多。

5.3 我观察到的关键趋势

结合我做过的实验，最值得留意的一个趋势是：整合阶段适当“保守”反而能提升整体效果。一开始我很激进，把语义合并阈值设到0.7，希望尽可能多地合并证据，把上下文信息密度降下来。结果发现合并错误率上升，生成的幻觉概率也明显提高。把阈值调到0.85以后，虽然上下文略微变长，但生成准确率是提升的。

另一个观察是：显式选择的收益在稀疏证据场景下远大于证据密集场景。如果检索结果本身又准又全，选择模块带来的增益有限；一旦场景变成“证据密度低、噪声大”，选择模块的价值立刻显现。这给了我一个启发：如果你要说服业务方接入这套方案，最好先拿“稀疏证据场景”的具体案例来展示，数据上的对比会非常有说服力。

6. 从论文到工程落地的几点个人体会

这个项目方向最打动我的地方，是它抓住了RAG系统在真实场景里的一个隐秘痛点：问题往往不是“检索不到证据”，而是“证据碎片化、噪声化之后，不知道该怎么用证据”。显式选择加整合这条技术路线，不追求模型结构的颠覆，而是把系统工程里“该做的环节”补上，这个思路很符合我在工业实践里的体感。

落地时最后想提醒三件事。第一，Agentic系统的设计一定要把“可观测性”放在高位，每个决策点都要有日志和中间产物输出，否则线上出了问题根本无从下手。第二，选择模块的阈值、整合模块的阈值，建议在部署时做成可配置项，不同领域的文档性质差异非常大，固定参数几乎不可能通吃。第三，不要为了“Agentic”而Agentic，如果你们的检索结果本身质量很高，证据密集，那加上显式选择可能只是增加延迟和成本，对效果没有明显帮助——这方案的真正价值，恰恰在“稀疏证据”这四个字出现的场景里。

最后再分享一个小技巧：如果你暂时没有条件做复杂的Agent循环，可以先只加入“显式上下文选择打分器+语义合并”这两个模块，挂在现有RAG流程上。这个轻量改造几乎不伤筋动骨，但在证据稀疏类问题上往往能带来立竿见影的改善。等效果验证完之后，再往迭代检索的方向演进，整个系统会稳很多。