基于证据的家庭检索：让RAG上下文涵盖问题的每个部分

五个相关片段仍可能让RAG系统缺少完整问题所需的全部信息。一旦问题需要多种不同类型的证据，这种矛盾就会消失。想象有人询问如何将应用设置、密钥以及授予工作负载的权限整合到同一套配置中。检索器可能会返回五段关于配置的优秀内容，这些片段都相关，但如果其中没有涉及凭证或权限的信息，整体上下文仍然不完整。

这正是简单top-k检索固有的缺陷：逐个对片段进行排序，无法判断答案所需的全部概念是否都已出现。

相关性不等于完整性

传统的处理流程会对各个片段进行排序并保留前 k 个。当某种类型的证据就能解决问题时，这种方法尚可；但当问题需要比较、综合多种信息源或多种真实依据时，它就显得不够可靠。假设排名靠前的五个片段都涉及“机密”信息，但答案还需要“服务账户身份”和“RBAC授权”这些信息。这种排序在局部看来合理，但从整体来看并不完整。

提高 top_k 的数值或许会有所帮助，但并不能保证效果。更大的上下文范围虽然可能带来重复内容、噪声、延迟以及成本问题，而且也无法确保缺失的概念会出现；此外，如果某个信息源家族在候选项中占主导地位，它很可能独自占据前20个位置。因此，该任务需要设置覆盖度约束：

Useful context = relevance + required-family coverage + trusted provenance - noise

证据族检索在保持常规相关性排序的同时加入了这一约束。

何为证据族

证据族是一组能够满足问题中某项要求的来源或段落。它不必等同于一个文件、主题标签、嵌入簇、检索策略或分块。以如何安全地部署应用程序这一问题为例，其对应的证据族可能包括入口路由、服务发现以及就绪状态检测。多个文档可属于“服务”证据族，而当文档的元数据与内容支持时，它也可能同时属于多个证据族。

在最终选择前规划证据

对于已识别的复合型问题，该项目会使用确定性证据规划器。从概念上讲，它的输出是一组(source_pattern, rescue_query)对，每个问题所需的证据族都会对应一个条目：

def evidence_plan(question: str):
    # Returns list of (family_pattern, rescue_query) tuples
    # for recognized composite question shapes
    if asks_about_workload_identity(question):
        return [
            (SECRET_SOURCE_PATTERN,      "Kubernetes Secret credentials Pod"),
            (SERVICE_ACCOUNT_PATTERN,    "Pod ServiceAccount workload identity"),
            (RBAC_SOURCE_PATTERN,        "RBAC least privilege RoleBinding"),
        ]
    return []  # unknown shapes continue through normal retrieval

其范围被刻意限定得较为狭窄，远非那种开放式的自主规划。已知重要的问题会拥有可预测的覆盖规则，而其他所有内容则通过常规检索来处理。关键在于可检验性：计划可以被检查与测试，因此，当团队发现某个家族信息缺失时，可以追溯问题出在问题检测、来源分类、候选项检索、重排序、过滤还是最终截断环节。

识别成员身份

在案例研究中，家族成员身份是通过将正则表达式与数据块的来源名称进行匹配来确定的：

pattern.search(str(chunk.source))

这是一种确定性来源契约，而非语义聚类。其优势在于精确性与可审计性：文档要么属于所声明的类别，要么不属于。相应的代价则是维护成本，因为重命名的文件和新集合需要更新其映射关系。一个可复用的平台应当优先使用明确的元数据，而非仅依赖文件名模式：

{
  "source": "security-policy.pdf",
  "document_id": "doc-123",
  "chunk_index": 17,
  "evidence_family": "access-control",
  "authority_tier": "official",
  "version": "2026-07"
}

成员资格判定简化为一次查找：chunk.metadata[“evidence_family”] == required_family。

找回缺失的家族

在初次检索之后，处理流程会统计每个计划中的家族对应的匹配候选项数量。如果某个家族的匹配数少于预期值，就会针对该家族发起有针对性的稀疏搜索，并使用相应的找回查询语句。

for family_pattern, rescue_query in plan:
    matches = [c for c in candidates if family_pattern.search(c.source)]

    if len(matches) < desired_candidate_count:
        # Targeted rescue — bounded, not an open retry loop
        rescued = sparse_search(rescue_query, top_k=wide_limit)
        candidates.extend(
            c for c in rescued if family_pattern.search(c.source)
        )

救援功能仅针对失踪的家庭启动，通过与该家庭合同相关的精准查询来筛选候选信息，从而提供多个选项，让重新排序系统能够选出最合适的结果，而非仅选择第一个出现的路径。

重新排序是挑选路径而非家庭

规划阶段决定哪些家庭必须被纳入考虑，而重新排序阶段则判断哪些可用片段最能回答问题。二者相辅相成。该项目的重新排序系统会综合多种信号并赋予不同权重：

0.4 × normalized cross-encoder score
+ 0.3 × normalized retrieval score
+ 0.3 × lexical overlap
+ conditional exact-token bonus

在候选人已排序的情况下，考虑家庭因素的筛选机制会为每个需要的家庭预留排名最高的匹配对象，然后再按整体排名填补剩余名额：

selected = []

# Step 1: reserve best chunk per required family
for family in required_families:
    best_match = first_ranked_match(family, ranked_chunks)
    if best_match:
        selected.append(best_match)

# Step 2: fill remaining slots by global rank
selected.extend(c for c in ranked_chunks if c not in selected)

final_chunks = selected[:top_k]  # constrained top-k, not an alternative to ranking

为何同一来源的片段需要保持在一起

早期版本的家庭感知选择机制在按文件名去重时出现了错误。假设存在一个NetworkPolicy文档，其中分别包含了默认拒绝行为、入站规则和出站规则的相关内容，而某个综合问题需要这些全部信息。如果选择机制要求每个文件名只能对应一个片段，那么其中两部分必要内容就会丢失。正确的去重策略应基于证据完整性要求：在消除冗余的同时确保信息覆盖全面，而且当不同内容分别满足不同的需求时，同一来源完全可以提供多个互补的片段。

权威性与相关性

一篇内容冗杂的研究论文在语义上可能与生产问题相似，而通用的控制面板指南也可能包含许多相同的查询术语。但两者都不应替代那些能直接回答问题的经过审批的操作手册。有三类信号必须保持区分：

Relevance:  Does this passage discuss the question?
Authority:  Is this an approved source of truth?
Coverage:   Which required evidence obligation does it satisfy?

一个分数不应仅代表全部三个指标。权威元数据必须能够经受住数据摄取、检索、融合、重排序、缓存以及API序列化等流程的考验，而不仅仅存储在向量数据库中。

在不损失覆盖范围的前提下进行修正性RAG处理

修正性RAG会对检索到的内容片段进行评分，当证据力度不足时可能会重新尝试检索。这种方法虽能提升精确度，但可能与证据规划产生冲突——因为某段看似仅部分相关的短文本，对于多文档综合分析而言可能至关重要。如果CRAG将其排除，答案中就会缺失必要的信息。为避免这种情况，该实现将经过验证的规划视为领域规则：在CRAG过滤之后，它会按照规划对每个类别进行全新的广泛搜索，然后选出最具权威性的文本片段。顺序很重要：

Retrieve broadly
→ shape and rerank candidates
→ reserve family coverage
→ grade evidence (CRAG)
→ restore validated required families
→ build context

成熟的设计可采用多种规划层级，具体选择取决于对问题结构的理解程度。在需要完全可审计性的高风险或受监管场景中，确定性规则更为适用；而更灵活的层级则适用于更广泛的领域及新型复合问题，这些方案始终需依据受控的分类体系进行验证。该模式还具有传递性：即便财务助手询问某笔转账是否允许以及需要何种审批，也无法用五段合理的政策条款来弥补账户数据缺失的问题，而家庭规划则明确了这些义务。

衡量覆盖范围

仅凭片段相关性无法验证具备家庭意识的信息检索系统。一个简单的家庭相关度指标就能暴露出这一缺陷：

Evidence-family recall = covered required families / total required families

# Example: Secret + RBAC covered, ServiceAccount missing
Evidence-family recall = 2/3 = 0.67

# This failure is invisible to standard chunk-relevance metrics

测试套件应包括寻找失踪的家庭、通过重新排序及CRAG机制维持运行、有效的替代来源、来自同一文档的互补内容片段、权威性过滤功能、数量少于所需家庭数的top-k限制，以及不会触发任何计划的问题。

故障模式

• 规划器因通用关键词触发了无关计划而产生过度响应。应使用短语组合及否定条件来避免此问题。
• 计划不完整，虽已找到声明中的家庭，但仍无法回答问题。缺失的概念既应纳入计划中，也应在回归测试中得到体现。
• 来源名称的变更导致正则表达式匹配 silently停止。语料库一致性测试应确保计划中的家庭能对应到真实的来源。

救援查询过度拟合评估问题。应围绕领域概念来构建这些查询，并通过改写语句及保留部分样本进行验证。

为弱证据提供保护的机制。每个类别需检索多个候选项，再进行排序后选定，同时仍需进行权威性及最低相关性检查。

上下文容量不足以处理过多类别，因此规划器必须进行优先级排序、合并兼容的证据或要求进一步澄清。

存在忽略部分证据的模型。完整的检索并不保证能实现完整的综合，因此提示语及忠实度检查应与规划方案相一致。

后续改进方向

接下来有几个值得进行的升级。应将家族标识信息存储在分版本的块元数据中，而非文件名中。需要制定一个域名证据分类体系，明确标识所有者及权限规则。对于特殊的复合查询，应添加带有严格约束的结构化规划器，并为每个家族单独调整最小相关性阈值。选择时可综合考虑相关性、覆盖度、冗余性以及标记使用预算。追踪功能应能显示规划过程及家族的覆盖情况。除了召回率之外，还需衡量规划器的精确度，自动检测语料库变化及来源文件重命名情况，并在封闭测试集上对比基于规则、基于分类器以及基于大语言模型的规划器表现。最后，当无法找到所需的家族时，系统应明确告知用户。

其目的并非让每个查询的检索过程都变得复杂，而是在问题确实需要多种类型证据时才投入额外精力。Top-k方法会筛选出最相关的文本片段，而证据家族检索则会提出另一个问题：最终上下文是否包含完整答案所需的各类证据？相关性用于判断某个文本片段是否有用，权威性用于判断是否可以信赖它，而覆盖度则用于判断答案是否完整。实际应用中的RAG系统需要这三者。