Top-K检索的问题，不一定是“召回不够多”
分析师做案头研究时，常见任务不仅是查一个数字，还包括追问：某家公司的供应链变化如何影响毛利率？一个行业趋势在哪些公司报告中得到相互印证？
语义检索擅长找到与问题表述最接近的片段，但关系链上的第二段证据可能与原问题并不相似。例如，问题提到公司A和经营指标，而关键中间证据出现在供应商B的文档中。继续提高Top-K可能带来更多噪声，却仍然没有解释两段材料为什么相关。
先路由问题，再选择检索方式
事实与定位问题
“2025年研发费用是多少？”优先走语义检索，返回最相关片段及原文出处。
关系与跨文档问题
“供应链变化如何影响利润？”在初始召回后，沿实体共现关系做有限两跳扩展。
证据不足问题
如果路径没有足够原文支持，不用图结构补出一个看似完整的故事，而是明确拒答或提示缺口。
轻量GraphRAG如何形成证据链
在AnalystCopilot中，我采用的是会话级实体共现证据图，而不是预先构建一个庞大的行业知识图谱：
- 上传PDF后保留正文、表格结构和chunk来源。
- 从片段中识别公司、产品、供应链和经营指标等实体。
- 同一证据片段中共同出现的实体建立关系，并保留source、chunk_id和原始文本。
- 关系类问题先做语义召回，再通过最多两跳BFS补充相邻证据。
- 生成答案时展示引用与证据路径，资料不足则拒答。
“最多两跳”不是普适最佳参数，而是对个人Demo的复杂度、噪声和响应成本做出的限制。生产场景仍需要用真实问题集校准跳数、阈值、图更新与权限隔离。
GraphRAG带来的不是免费提升
- 实体抽取误差：别名、缩写和同名实体会制造错误关系。
- 关系不等于因果：共现只能说明材料中存在连接，不能自动证明影响方向。
- 路径噪声：图越大、跳数越多，越容易引入与问题无关的证据。
- 时效与权限：旧文档和无权限资料不能因为进入图中就被继续召回。
- 成本与延迟：解析、建图、扩展和重排都增加链路复杂度。
产品经理如何判断该不该做
我会先用一组真实任务回答四个问题：普通RAG失败是否主要来自跨片段关系缺失？关系问题在目标任务中占比是否足够高？新增路径能否绑定原文并被用户核验？提升是否值得额外的延迟、成本和维护复杂度？
如果用户只是查制度、找字段或总结单篇文档，做好解析、metadata、语义检索和引用，通常比引入图更重要。只有当跨实体、跨文档推理是稳定需求，且两跳证据能提高可核验性时，GraphRAG才有明确的产品价值。
我的设计原则：先定义答案需要什么证据，再决定检索结构。GraphRAG的价值不是让架构更高级，而是让原本分散的证据关系变得可发现、可展示、可复核。
证据边界：AnalystCopilot使用轻量实体共现图和两跳证据扩展，不将其包装为成熟行业知识图谱。当前单元测试覆盖路由、两跳溯源和删除同步；真实研报对照评测仍是继续迭代的门槛。