ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

官方数据与独立估算对不上号:从同一经济现象的两套读数,看 RAG 知识库该信谁、怎么标

官方数据与独立估算对不上号:从同一经济现象的两套读数,看 RAG 知识库该信谁、怎么标

官方数据与独立估算对不上号:从同一经济现象的两套读数,看 RAG 知识库该信谁、怎么标

一个熟悉又尴尬的场景

做 RAG(检索增强生成)系统的人迟早会撞上这个问题:用户问一个事实性问题,检索环节召回了两条文档,一条说 A,另一条说非 A,而且两条看起来都挺“权威”。这时候,检索器、重排器、生成模型,任何一环都可能“默默替用户选边”——通常是比较隐蔽的那一环:相似度打分恰好让某一条排在了前面,LLM 就顺着它写了下去,用户完全不知道另一套说法的存在。

这不是假设性的问题。现实世界里,“同一事实存在多个互相矛盾的权威来源”是长期存在的真实现象,经济数据就是最典型的例子。与其在系统里假装世界只有一个版本的事实,不如把这种冲突显式地建模进知识库。下面借一个真实案例展开。

案例:同一个 5.2%,两套叙事

根据彭博的报道《中国经济去年真的增长了5.2%吗? 并非人人都赞同》,围绕 2023 年中国经济增速存在官方数据与独立估算两条并行路线:一方面,由于对中国官方经济数据的准确性存在由来已久的怀疑,“另起炉灶独立估算的做法颇为常见”;另一方面,官方与独立估算在部分问题上其实一致——比如都认同防疫限制取消后经济确实实现了增长(国内航班数量、消费类企业收入等官方数据都显示了这一点),也都认同地产建设剧烈下滑、地方融资吃紧、出口走低构成压力。

分歧点同样具体:报道指出,双方看法存在分歧的包括投资数据——官方数据显示制造业和基建支出飙升,抵消了房地产造成的拖累。

这个案例对 RAG 设计者的价值在于,它不是简单的“真 vs 假”,而是“口径不同的两套可信读数,各自覆盖事实的不同侧面”。如果你的知识库里同时收录了官方统计和第三方分析,用户问“去年中国经济怎么样”,你怎么办?

错误做法:让相似度排序替用户做决定

最常见的隐性失败模式是:两条文档都进了上下文,但排序靠前的那条主导了生成,另一条被 LLM 当作背景噪音忽略。结果用户得到一个斩钉截铁的单一答案,却不知道知识库里本来就存在分歧。更糟的是,这种选边是偶然的——换个 embedding 模型、换种分块方式,答案可能就翻转了。

建议一:来源可信度分级,但分级不等于淘汰

在入库阶段就给每个文档打上来源标签,至少区分几类:

  • 官方/一手:政府统计、监管公告、企业财报原文。
  • 专业二手:主流财经媒体、研究机构报告。
  • 观点/估算:明确标注为分析、预测或独立估算的内容。

关键原则:低级别来源不删除,只降权并打标。经济数据的例子说明,“独立估算”与“官方数据”可能长期并存且各有支持者,删掉任何一边都会让知识库失去一个视角。分级的目的不是裁判谁对,而是让下游知道每条信息“是什么性质的说法”。

建议二:检索结果中同时呈现冲突读数,并标注口径

具体可以这样落地:

  1. 冲突检测:对同一实体+同一指标+同一时间的文档做聚类,如果数值或结论差异超过阈值,标记为“冲突簇”。经济类文档可以用抽取出的数值直接比对;非数值结论可以用更宽松的语义判断,宁可误报不可漏报。
  2. 同簇共存:命中冲突簇时,不按相似度只留一条,而是把簇内各来源的代表性片段一起送入上下文,每条前面附上来源级别和口径说明,例如“官方统计口径”还是“第三方独立估算口径”。
  3. 生成端约束:在 prompt 中要求 LLM 对冲突读数分点呈现、各自注明来源和口径,禁止静默择一。如果用户要的是决策建议,可以让模型说明“不同口径下结论如何变化”,而不是替用户宣布哪个数是“真的”。

回到案例:用户问“2023 年中国经济表现如何”,理想的输出是——增长这一点双方共识,投资数据存在官方(制造业与基建支出飙升)与独立估算(对官方投资数据存疑)的分歧,并注明各自口径。这比一个孤零零的“5.2%”信息量大得多,也更诚实。

建议三:口径与时间元数据要作为一等公民

经济数据的另一个坑是“目标”与“实际”的混淆。同一篇彭博报道《中国多数地方政府下调今年通胀目标 从实际出发更加务实》提到:中国从 2001 年开始发布年度消费通胀目标;发达经济体央行通常将 2% 设为通胀目标,而中国央行有多重目标(增长、汇率等),并无单一通胀目标;报道还引述彭博调查的分析师预测中值,今年中国 CPI 涨幅料为 0.8%。

注意这里面至少有三种性质不同的数字:历史实际值、政策目标值、分析师预测中值。如果知识库不给每条数字打上“实际/目标/预测”的口径标签,检索时“2% 的通胀目标”和“0.8% 的预测涨幅”就可能被混为一谈,生成出荒诞的对比结论。所以元数据至少要包含:来源名称、来源级别、数据性质(实际/目标/预测/估算)、时间范围、统计口径。

适用范围与局限

这套做法适用于事实密集、存在多来源叙事的领域:宏观经济、行业分析、政策解读、医药指南等。对于“API 参数怎么写”这类客观技术事实,冲突通常意味着某一方过时了,直接按时间戳和官方文档优先级处理即可,不需要双轨呈现。

局限也很明显:冲突检测在非数值、模糊表述的场景下误报率高;把多条冲突读数塞进上下文会占用 token,也需要更强的生成端指令跟随能力;来源分级本身是人工判断,带有主观性——你可以规定“官方优先”,但不能假装这个规定消除了分歧,它只是明确了你的系统采用的编辑立场,而这个立场最好也对用户透明。

结语

RAG 系统的诚实程度,不体现在它答得多流畅,而体现在它是否把知识库里真实存在的分歧告诉了用户。官方数据与独立估算长期对不上号,是世界的常态而非知识库的 bug。把可信度分级、冲突同簇呈现、口径标注做进检索链路,让“选边”这件事回到用户手里——这才是一个值得信任的知识库应有的样子。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中;资料内容与适用范围以原始页面为准。

  • 中国经济去年真的增长了5.2%吗? 并非人人都赞同
  • 中国多数地方政府下调今年通胀目标 从实际出发更加务实
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进