跨文档问答："上个月项目复盘里提了哪些风险"，AI 翻遍你权限内的文档找答案

一、问题定义：为什么"翻遍文档"比"读一篇文档"难得多

单文档问答（Single-Document QA）已经在工程上相对成熟：给定一篇长文，模型定位相关段落并生成答案。但"上个月项目复盘里提了哪些风险"这句话，隐含的检索范围是一个文档集合，而非单篇文档。这个集合可能包含：三份会议纪要、两份周报、若干封邮件、一份风险登记表、以及散落在 IM 里的讨论记录。答案不是"某一段话"，而是"多个文档中风险条目的并集"。

这就把问题从"阅读理解"推向了"信息聚合 + 归因"。笔者认为，跨文档问答的困难可以拆成四个正交维度：

本文评述：很多团队把跨文档问答当成"把 top-k 调大一点"的问题，这是典型的误判。k 值增大只提升召回，不解决聚合与归因。真正需要的是在检索层引入文档级路由，在生成层引入证据结构化。这两点构成了后文所有技术选择的判断标准。

二、分析主线：权限感知检索—跨文档聚合—证据链生成

为了让全文逻辑不散，这里先确立一条贯穿始终的主线。跨文档问答系统的完整链路可以抽象为三个阶段，每个阶段有明确的输入、输出与失败模式。

阶段	核心任务	关键输入	典型失败模式
权限感知检索	在 ACL 约束下召回候选片段	查询、用户身份、文档元数据	权限泄漏、时间过滤失效
跨文档聚合	合并同类项、去重、补全	候选片段集合	重复列举、遗漏、张冠李戴
证据链生成	生成带引用的结构化答案	聚合后的证据	幻觉引用、引用错位

本文评述：把这三个阶段分开设计，而不是交给一个大模型端到端处理，是工程上最关键的决策。原因在于三者的失败模式完全不同，需要不同的可观测指标与回退策略。端到端方案在 demo 阶段表现惊艳，但在企业环境中一旦出现权限泄漏或引用错位，就无法定位是哪一环出了问题。

三、文档解析与分块：跨文档问答的地基

3.1 异构文档的统一表示

企业文档的格式极其杂乱：PDF、Word、Markdown、Confluence 页面、飞书文档、邮件正文、工单系统记录。第一步是把它们统一成一种中间表示。工程上通常采用"结构化文本 + 元数据"的组合：正文保留标题层级，元数据记录来源、作者、创建时间、修改时间、ACL 标签。

这里有一个容易被忽视的点：时间元数据的准确性直接决定"上个月"这类查询能否成立。很多系统的文档时间戳取自文件系统 mtime，而 mtime 会因为一次批量同步被全部刷新，导致时间过滤失效。正确做法是从文档内容或业务系统中提取"业务时间"（如会议纪要的会议日期），而非依赖文件系统时间。

3.2 分块策略：跨文档场景下的特殊考量

分块（Chunking）是 RAG 系统最基础也最容易做错的环节。常见的固定长度分块（如 512 token）在单文档问答中尚可，但在跨文档场景下会带来两个问题：一是列表型内容（风险清单）被切断，二是跨文档的语义关联被破坏。

业界近年倾向于结构感知分块（structure-aware chunking）：按标题层级切分，保留父标题作为上下文前缀。对于列表项，尽量保持完整；对于表格，转换为 Markdown 或保留结构化表示。Anthropic 在 2024 年的上下文检索（Contextual Retrieval）工作中提出，为每个 chunk 附加一段由模型生成的上下文说明，可显著降低检索失败率（来源：Anthropic, "Introducing Contextual Retrieval", 2024）。

本文评述：上下文检索的思路值得借鉴，但要注意成本。为每个 chunk 生成上下文说明意味着对全量文档做一次额外的 LLM 调用，在百万级文档的企业库中成本可观。笔者的建议是分层处理：对高频访问的文档做上下文增强，对长尾文档保持基础分块，用检索频率驱动优化优先级。

3.3 分块参数的工程建议

文档类型	建议块大小	重叠	分块依据
会议纪要	按议题切分	1 句	标题 + 列表项
周报	300–500 token	15%	段落
邮件	整封或按引用切分	无	邮件边界
风险登记表	按行	表头	表格行

表中参数为工程经验值，非严格实验结论，实际需根据文档分布做网格搜索。可参考 LlamaIndex 的 Node Parser 文档 与 LangChain 的 Text Splitters 指南 做参数实验。

四、权限感知检索：ACL 与检索的耦合设计

4.1 权限过滤的三种时机

权限过滤可以发生在检索前、检索中、检索后三个时机，各有取舍：

• 检索前过滤（pre-filter）：先根据用户 ACL 缩小文档集合，再检索。安全性最高，但在文档量巨大时可能拖慢查询。
• 检索中过滤（in-filter）：在向量索引中携带 ACL 字段，检索时作为过滤条件。主流向量库（如 Milvus、Qdrant、Weaviate）都支持 metadata filter，这是当前最实用的方案。
• 检索后过滤（post-filter）：先检索 top-k，再剔除无权文档。实现简单，但存在严重风险——如果 top-k 中大量文档被剔除，召回质量骤降；更危险的是，如果过滤逻辑有 bug，会直接导致权限泄漏。

本文评述：post-filter 是很多团队的第一版实现，也是事故高发区。笔者认为，只要系统面向多租户或多角色用户，就应当采用 in-filter 或 pre-filter，把权限作为检索的一等约束而非事后补丁。可参考 Milvus 布尔表达式过滤 与 Qdrant Filtering 的实现方式。

4.2 ACL 建模：从扁平列表到继承树

企业权限模型通常不是简单的"用户-文档"二元关系，而是带有继承的树形结构：部门→项目→文档，或空间→页面→子页面。检索时，用户的有效权限是其在权限树中所有可达节点的并集。

工程上常见的做法是在索引时把文档的 ACL 展开为"可见用户组列表"或"可见用户 ID 列表"，检索时用用户所属组做交集。这种方式查询快，但代价是权限变更时需要重建索引。折中方案是维护一张"用户组-文档"的倒排表，检索时先查出用户可见的文档 ID 集合，再作为过滤条件传入向量库。

# 伪代码：权限感知检索的典型流程
def permission_aware_retrieve(query, user, top_k=50):
    # 1. 解析用户有效权限（含继承）
    visible_doc_ids = acl_service.get_visible_docs(user.id)
    # 2. 时间约束解析（"上个月" → 时间区间）
    time_range = parse_time_constraint(query, ref_date=today)
    # 3. 构造过滤条件
    filter_expr = {
        "doc_id": {"$in": visible_doc_ids},
        "business_time": {"$gte": time_range.start,
                          "$lt":  time_range.end}
    }
    # 4. 向量检索 + 关键词检索（混合）
    dense_hits = vector_store.search(query_vec, filter=filter_expr, k=top_k)
    sparse_hits = bm25_index.search(query, filter=filter_expr, k=top_k)
    # 5. 融合
    return rrf_fuse(dense_hits, sparse_hits)

4.3 权限泄漏的防御性设计

即使检索层做了过滤，生成层仍可能泄漏信息。例如模型在总结时"脑补"出未授权文档中的内容。防御性设计包括：在生成 prompt 中显式声明证据边界；对生成结果做引用校验，确保每个事实性陈述都能对应到授权文档；对无法溯源的陈述做降级处理。

五、混合检索与重排序：召回与精排的协同

5.1 为什么必须混合检索

"上个月项目复盘里提了哪些风险"这个查询包含两类信号：语义信号（"风险"的语义相近表达，如"隐患""阻塞""不确定性"）和字面信号（"项目复盘""上个月"这类需要精确匹配的词）。稠密向量检索擅长前者，稀疏检索（BM25）擅长后者。单一检索方式在跨文档场景下召回率往往不足。

混合检索的融合策略主要有两种：加权求和与倒数排名融合（RRF）。RRF 因为不需要调权重、对分数尺度不敏感，在实践中更受欢迎。其公式为：对每个文档，累加其在各检索结果中排名的倒数。

# RRF 融合（k 通常取 60）
def rrf_fuse(*result_lists, k=60):
    scores = {}
    for results in result_lists:
        for rank, doc_id in enumerate(results, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda x: -x[1])

本文评述：RRF 的 k 值常被当作玄学参数，其实它控制的是"头部结果的相对优势"。k 越小，排名第一的文档优势越大；k 越大，各排名之间的差距被拉平。对于跨文档问答这种需要广覆盖的场景，笔者建议 k 取 60 左右（这也是原始论文的默认值），让更多文档有机会进入重排序阶段。

5.2 重排序：把真正相关的证据提到前面

重排序（Reranking）使用交叉编码器（cross-encoder）对查询-文档对做精细打分。相比双塔检索，交叉编码器能看到查询和文档的交互，精度更高但速度慢，因此只用于对 top-k 候选做精排。

常用的重排序模型包括 BGE-Reranker 系列、Cohere Rerank、以及基于 LLM 的列表式重排。2024 年以来，基于 LLM 的重排序（如 RankGPT 思路）在复杂查询上表现更好，但延迟和成本更高。工程上通常先用小型交叉编码器做粗排，再对 top-10 用 LLM 做精排。

阶段	方法	候选量级	延迟量级
召回	稠密 + 稀疏混合	10²–10³	10–50 ms
粗排	小型交叉编码器	50–100	50–200 ms
精排	LLM 列表重排	10–20	0.5–2 s

延迟数据为公开基准与工程经验的综合估计，实际取决于硬件与模型规模。可参考 BGE-Reranker-v2-m3 模型卡 与 Cohere Rerank 文档。

六、跨文档聚合：从片段到全局视图

6.1 聚合的三个子任务

拿到重排序后的片段集合后，系统需要把它们组织成"风险清单"。这个过程包含三个子任务：

• 去重（deduplication）：同一风险可能在多份文档中被提及，需要合并。例如"第三方 API 交付延迟"在周报和纪要中都出现，应合并为一条并列出多个出处。
• 归类（clustering）：把语义相近的风险归为一类，如"进度风险""技术风险""资源风险"。
• 补全（completion）：某些风险只提到了一半信息（如只说了风险名，没说影响），需要从其他文档补全。

6.2 用结构化输出约束聚合

让 LLM 自由生成"风险清单"很容易出现格式漂移和遗漏。工程上更可靠的做法是定义结构化 schema，让模型填充。例如：

{
  "risks": [
    {
      "title": "第三方 API 交付延迟",
      "category": "进度",
      "evidence": [
        {"doc_id": "weekly_2024_05_w3", "quote": "供应商反馈接口联调推迟两周"},
        {"doc_id": "review_2024_05", "quote": "外部依赖存在交付不确定性"}
      ],
      "confidence": "high"
    }
  ]
}

这种"证据-结论"分离的结构有两个好处：一是便于程序化校验（每条风险必须有至少一条 evidence），二是便于前端渲染引用链接。

本文评述：结构化输出是跨文档聚合从"能用"到"可靠"的关键一步。笔者认为，凡是需要跨文档汇总的任务，都应强制模型输出"结论 + 证据"的配对结构，而不是自然语言段落。这不仅降低幻觉，也让答案可审计。可参考 LangChain Structured Outputs 与 OpenAI 的 Structured Outputs 指南。

七、多跳推理与 GraphRAG：处理"分散式答案"

7.1 什么是多跳问题

"上个月项目复盘里提了哪些风险"本身是单跳问题（找到风险条目即可）。但用户往往会追问："这些风险里哪些还没解决？"这就变成多跳：先找到风险，再找到对应的解决状态，可能需要跨文档关联。

多跳问答（Multi-hop QA）在学术界有长期研究，经典数据集如 HotpotQA、MuSiQue 都要求模型在多个段落间推理。企业场景的多跳往往更"接地气"：不是逻辑推理，而是实体关联。

7.2 GraphRAG 的思路与适用边界

微软在 2024 年提出的 GraphRAG（来源：Microsoft Research, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization", 2024）通过构建实体-关系图，并用社区检测算法生成分层摘要，来解决"全局性问题"（如"这个数据集的主要主题是什么"）。

GraphRAG 对跨文档问答的启示在于：当答案需要跨文档聚合时，图结构比扁平片段更能表达"同一实体在不同文档中的出现"。例如"风险 R1"在纪要、周报、邮件中都有提及，图结构可以把这个实体和它的所有提及连起来。

本文评述：GraphRAG 的索引成本很高（需要 LLM 抽取实体关系），并非所有场景都值得。笔者的判断标准是：如果查询中频繁出现"哪些""汇总""整体上"这类全局性词汇，且文档间存在大量实体交叉，那么图结构有收益；如果查询主要是"某文档说了什么"这类局部问题，扁平 RAG 更划算。可参考 GraphRAG 官方文档 与 GitHub 仓库。

7.3 轻量级替代：实体链接 + 元数据关联

如果不想承担 GraphRAG 的索引成本，可以用更轻的方案：在索引时抽取文档中的关键实体（项目名、人名、风险编号），建立"实体-文档"倒排表。检索时先定位实体，再扩展相关文档。这种方式在工程上更容易落地，代价是表达能力弱于完整图结构。

八、证据链生成与引用溯源

8.1 引用的三个层次

引用不是简单地附上文档链接，而应分三个层次：

• 文档级引用：指出答案来自哪几份文档。
• 段落级引用：指出具体段落或片段。
• 句子级引用：指出支撑某个具体陈述的原句。

跨文档问答至少要做到段落级引用，理想情况做到句子级。实现方式是在生成时要求模型输出引用标记（如 [1][2]），并在后处理阶段校验每个标记对应的片段确实包含支撑内容。

8.2 引用校验：对抗幻觉引用

模型可能生成"看起来合理但实际不存在"的引用。校验方法包括：检查引用的 doc_id 是否在候选集合中；检查引用的原句是否真实存在于文档中（字符串匹配或语义匹配）；检查被引用片段与陈述的语义一致性（用 NLI 模型判断是否蕴含）。

本文评述：引用校验环节常被省略，但它是企业级系统能否上线的分水岭。笔者认为，任何面向专业用户的问答系统都应把"引用可验证"作为硬性指标，宁可答案短一些，也不能出现无法溯源的陈述。可参考 Enabling Large Language Models to Generate Text with Citations 等工作的思路。

九、评测基准与指标体系

9.1 公开基准

跨文档问答的公开评测集包括：

基准	特点	适用场景
HotpotQA	多跳、需跨段推理	多跳能力评估
MuSiQue	多跳、抗捷径	推理链评估
MultiHop-RAG	基于新闻的多跳 RAG 基准	RAG 多跳评估
RAGAS	评估框架而非数据集	RAG 全链路指标

这些基准主要面向英文，中文企业场景的评测集仍较稀缺。实践中常用做法是自建内部评测集：从真实查询日志中采样，人工标注"标准答案 + 证据文档"，形成回归测试集。

9.2 指标体系

跨文档问答的评估应覆盖检索、聚合、生成三个层面：

• 检索层：Recall@k、MRR、nDCG。重点看"证据文档是否被召回"。
• 聚合层：风险条目的查全率与查准率、去重准确率。
• 生成层：答案忠实度（faithfulness）、引用准确率、答案完整性。

RAGAS 框架提供了 faithfulness、answer relevancy、context precision 等指标，可作为起点（来源：Es et al., "RAGAS: Automated Evaluation of Retrieval Augmented Generation", 2023）。

十、工程落地路径：一个可运行的最小系统

10.1 技术栈选型

环节	可选方案	备注
文档解析	Unstructured、LlamaParse、PyMuPDF	按格式选型
向量库	Milvus、Qdrant、Weaviate、pgvector	需支持 metadata filter
稀疏检索	Elasticsearch、BM25、SPLADE	可与向量库分离
重排序	BGE-Reranker、Cohere Rerank	按延迟预算选择
编排	LangChain、LlamaIndex、Haystack	按团队熟悉度选择

10.2 分阶段实施步骤

1. 阶段一（1–2 周）：打通文档接入与解析，建立统一元数据 schema，实现基础向量检索。目标：能回答单文档问题。
2. 阶段二（2–3 周）：接入 ACL 过滤与时间过滤，实现混合检索 + 重排序。目标：检索范围正确，权限不泄漏。
3. 阶段三（2–3 周）：实现结构化聚合与引用生成，接入引用校验。目标：答案可溯源。
4. 阶段四（持续）：建立评测集与监控，迭代优化分块、重排、prompt。

本文评述：很多团队试图一步到位上 GraphRAG 或多智能体，结果卡在基础设施上。笔者认为，按上述四阶段推进，每阶段都有可交付、可验证的能力，是更稳妥的工程路径。可参考 LlamaIndex Production RAG 指南 与 RAG 从入门到生产（视频教程）。

10.3 可观测性建设

生产系统必须记录每次查询的完整链路：查询改写结果、召回文档 ID、重排序分数、生成答案、引用校验结果。这些日志既是排障依据，也是迭代评测的数据来源。建议接入 LangSmith、Phoenix 或自建 trace 系统。

十一、前沿预判与开放问题

11.1 长上下文 vs 检索增强

随着模型上下文窗口扩展到百万 token，一种观点认为"检索会被长上下文取代"。本文评述：在企业场景下这个判断不成立。原因有三：一是权限过滤必须在检索层完成，把全量文档塞进上下文无法保证权限边界；二是成本，百万 token 的推理成本远高于检索 top-10；三是可溯源性，长上下文中的引用定位比检索片段更难。长上下文更适合作为检索后的"精读"手段，而非替代检索。

11.2 智能体化检索

2024 年以来，Agentic RAG 成为热点：让模型自主决定检索什么、检索几次、是否需要追问。对于跨文档问答，智能体可以处理"先找风险，再找状态"这类多步任务。但智能体也带来新的不确定性——检索次数不可控、延迟波动大。工程上通常设置最大步数与超时回退。

11.3 开放问题

• 如何在保证权限安全的前提下，降低 ACL 过滤对检索性能的影响？
• 跨文档聚合的去重与归类，能否用更轻量的方法替代 LLM？
• 中文企业文档的跨文档评测集如何构建？
• 引用校验的自动化程度能否达到生产可用？

十二、结语

"上个月项目复盘里提了哪些风险"这句话，看似是自然语言理解问题，实则是检索系统、权限系统、聚合逻辑、溯源机制四者的协同工程。本文以"权限感知检索—跨文档聚合—证据链生成"为主线，把这条链路拆解为可实施、可验证的步骤。

本文评述：跨文档问答的成熟度，最终不取决于模型有多强，而取决于工程细节有多扎实——时间元数据是否准确、权限过滤是否前置、聚合是否结构化、引用是否可校验。这些"不性感"的环节，才是企业级系统能否真正落地的分水岭。

主要参考文献