你的RAG应用正在一本正经地胡说八道？手把手教你搭建幻觉检测防火墙，让AI不再满嘴跑火车！本文将带你穿透大模型“胡说八道”的迷雾，从幻觉的本质定义到自动检测兵器谱，从量化打分到工程化闭环，手把手教你建立一套靠谱的RAG幻觉评估体系。

目录

1. 先搞清楚：RAG里的幻觉到底长啥样
2. 肉眼识别法：人工审查的基线与陷阱
3. 自动检测兵器谱：NLI、向量与Judge LLM
4. 量化评估体系：从二元判断到连续分数
5. 工程化落地：检测Pipeline与持续监控

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》119.[第12章 RAG评估体系] 幻觉检测：识别和量化模型编造内容

都说“Talk is cheap, show me the code”，但在大模型这，Talk不仅不cheap，还特别贵——贵到一旦它开始一本正经地胡说八道，你的用户可能直接流失，你的老板可能直接发飙。

很多新手同学觉得，RAG不就是给大模型外挂个知识库吗？检索几篇文档塞进去，模型自然就变老实了。结果呢？上线没几天，用户截图发来：明明文档里写的是“年假5天”，你的AI偏说是“10天，且可以顺延”。这时候你才意识到，原来RAG不是幻觉的万能解药。

更扎心的是，如果你连模型在什么时候撒谎、撒了多少谎都搞不清楚，那你所谓的“优化”根本就是盲人摸象。今天我们就把“幻觉检测”这块硬骨头啃下来，让你的RAG应用从“可用”真正走向“可信”。

---

1. 先搞清楚：RAG里的幻觉到底长啥样

咱们先给幻觉做个“亲子鉴定”。在大模型圈子里，幻觉通常指模型生成的内容与事实不符，或者是凭空捏造出来的。但在RAG场景下，事情要更复杂一点。

因为你引入了外部检索上下文，所以幻觉至少得分成三大门派。

第一，事实性幻觉。就是模型说的东西，跟真实世界对不上。哪怕你检索了一堆资料，模型也可能对资料视而不见，搬出自己预训练时的“老黄历”。比如文档里明明写着“本产品不支持Windows 7”，模型却来一句“当然支持，请放心安装”。这种属于最危险的，直接误导用户。

第二，忠实性幻觉。模型说的内容，跟它自己拿到的检索上下文对不上。换句话说，上下文里没这么说，或者相反，模型却强行脑补。这是RAG场景里最常见的。比如检索结果是“退款需要在7个工作日内处理”，模型回答成“退款需要7天”。数字相近，意思可能差很远，甚至上下文根本没提“7天”这个数字。

第三，上下文冲突型幻觉。这个比较隐蔽。你检索回来的Top-K文档之间本身就存在矛盾，模型被搞懵了，于是选择性地挑了一句，或者干脆综合出了一个“四不像”的答案。比如技术文档V1.0说“接口A已废弃”，V2.0说“接口A仍然可用”，模型最后回答“接口A半废弃状态”。这其实不是模型一个人的锅，但结果依然是幻觉。

所以你看，RAG里的幻觉不是单一病症，而是综合征。分不清类型，后面的检测和量化就全乱套了。

来，看张图，直观感受一下：

新手最容易犯的错，就是把“模型回答错了”统一归结为幻觉，然后疯狂调 prompt，结果发现根本不治本。

我举个例子。你做了一个公司内部制度问答Bot。用户问：“我们公司的出差补贴标准是多少？”检索系统召回了一段2023年的旧制度，上面写着“每天200元”。但财务部门2024年已经更新成了“每天300元”，只是新文档因为分块或者向量相似度问题没被检索到。模型基于旧文档回答“200元”。

这时候你去调 prompt，写什么“请基于最新文档回答”，有意义吗？没意义！因为问题是检索召回的滞后性，不是生成幻觉。你折腾了一周模型，最后发现是向量库没更新，气不气？

还有一种典型误区，是认为“只要检索到了正确答案，模型就一定会听话”。太天真了。大模型的预训练知识就像它的肌肉记忆，非常顽固。如果你的 prompt 没有明确约束，或者上下文里的答案不够显著，模型很容易“自由发挥”。比如上下文里有“Python 3.10”，模型顺口说成“Python 3.9”，因为它训练数据里3.9太常见了。

更隐蔽的误区是忽略上下文冲突。很多同学做RAG，检索Top-5直接全塞进 prompt，根本不管这5段有没有矛盾。模型被喂了一肚子互相打架的信息，不 hallucinate 才怪。比如你的知识库里有新老两版API文档。用户问“用户认证接口的速率限制是多少？”，Top-1召回的是旧文档“100次/分钟”，Top-2是新文档“500次/分钟”。模型左右为难，最后回答“速率限制在100到500次之间”。用户看了直接懵圈：到底是多少？

所以第一步，你要建立一个“幻觉归因”的检查清单。每次发现 badcase，别急着改代码，先问三个问题。

第一，检索召回的对吗？用同样的query去搜你的向量库，看看正确答案在不在Top-K里。如果不在，这是检索问题，先修检索。

第二，检索回来了，但模型没看吗？把检索到的上下文和模型回答摆在一起，逐句比对。如果上下文里有明确答案，模型却答错了，这才是忠实性幻觉，该修 prompt 或者加 few-shot。

第三，上下文本身有没有矛盾？如果Top-K里既有A说法又有B说法，那你得考虑做重排序，或者加一层“冲突检测”与“多源融合”的逻辑。实在不行，让模型明确告知用户“不同来源存在差异”。

只要做好归因，你的优化就不再是玄学，而是科学。别让模型背不该背的锅，也别让检索漏洞躲在模型背后。

小结：搞清楚幻觉的家族谱系和根因，是你搭建评估体系的地基。地基不牢，后面的检测和量化都是空中楼阁。

---

2. 肉眼识别法：人工审查的基线与陷阱

在搞自动化之前，你得先学会用肉眼识别幻觉。人工评估是一切自动指标的“上帝标准”。没有可靠的人工标注，你后面用啥模型当裁判都是扯淡。

人工审查通常分两条路：有参考评估和无参考评估。

有参考评估，就是你有标准答案。评估员拿着标准答案，看模型的回答对不对。这适合封闭域问答，比如考试题、产品FAQ。

无参考评估，就是没有标准答案，或者标准答案根本不存在。这时候需要领域专家根据常识和上下文，判断模型有没有胡说。虽然主观性强，但在企业落地场景里非常常见。

新手做人工评估，最容易踩的坑就是“拍脑袋定标准”。

比如，你找三个实习生来标注幻觉，你给他们的指令是：“看一下这个回答，错的就打个叉。”结果呢？三个人对同一个回答，一个打叉，两个打勾，一致性惨不忍睹。为什么？因为“错”的定义太模糊了。是把数字搞错了算错，还是表述不严谨也算错？是严格等同于幻觉，还是包含理解偏差？

还有一个经典错误，是用字符串匹配或者简单的包含关系来判断对错。来看个案例：

标准答案：“本服务支持Python 3.8及以上版本。”
模型回答：“目前兼容Python 3.9、3.10与3.11环境。”

如果你写个脚本判断模型回答是否包含“Python 3.8”，那答案是不包含，直接被判错。但实际上模型回答不仅没错，还更具体。这种“伪幻觉”会严重干扰你的评估数据。

另外，无参考评估时，新手常常找非领域专家来做标注。让前端同学去标注医学报告，让实习生去判断法律条文的细微差别，结果必然是噪声大于信号。在金融领域，一个回答里的“预期收益率”和“业绩比较基准”是两个完全不同的概念。模型如果混为一谈，非金融专业的标注员可能觉得“差不多”，但用户因此产生投资误解，那就是大事故。

人工评估要想靠谱，必须建立 Rubric。把笼统的“对错”拆成可操作的维度。

举个例子，对于RAG问答，你可以设计一个三级量表：

0分（严重幻觉）：回答中包含与检索上下文直接矛盾的信息，或者凭空捏造关键事实。比如上下文说“不支持”，模型说“支持”。

1分（轻微偏差）：回答在细节上不够精确，但没有根本性错误，或者遗漏了部分限制性条件。比如上下文说“7个工作日内”，模型说“7天内”。

2分（完全忠实）：回答准确反映了上下文内容，无编造、无矛盾。

对于每个样本，要求至少两名标注员独立打分，然后计算 Cohen’s Kappa 或 Fleiss’ Kappa 一致性系数。如果一致性低于0.6，说明你们的标准还不够清晰，得回去修 Rubric，而不是继续盲目标注。

在有参考评估里，也别用字符串匹配了，改用语义相似度或者让标注员判断“含义是否等价”。实在要自动化初筛，可以用Sentence-BERT算相似度作为辅助，但最终裁定权要留给懂业务的人。

来看个流程图：

这样做的好处是，你的人工评估结果终于可以信了。有了可信的Ground Truth，你后面的自动化检测才有了对齐的目标。

小结：人工评估是地基，但地基不牢，后头的自动化都是沙上建塔。花点时间把Rubric和一致性做好，后面能省十倍的心。

---

3. 自动检测兵器谱：NLI、向量与Judge LLM

好，人工评估虽然准，但成本太高、速度太慢，无法应对生产环境的海量数据。这时候就得请自动检测上场。

目前业界主流有三把兵器：基于NLI的检测、基于向量语义相似度的检测、以及基于大模型裁判的检测。

第一把兵器，NLI。它的核心逻辑是：把检索到的上下文当作前提，把模型生成的回答中的某个陈述当作假设，然后用一个NLI模型去判断这两者的关系是蕴含、矛盾，还是中立。如果出现矛盾，那就是妥妥的幻觉。

第二把兵器，向量语义相似度。把上下文和回答分别编码成向量，算余弦相似度。相似度低，说明回答可能偏离了上下文。但这把兵器比较糙，容易误判。

第三把兵器，Judge LLM。用一个能力更强、更可靠的大模型来当裁判，给它设计好评判标准和 few-shot 示例，让它去判断原模型的回答有没有幻觉。

新手最容易犯的错，是迷信某一把兵器，或者组合打得稀烂。

先说NLI。很多同学直接用通用的NLI模型，拿来判断专业领域文档，发现准确率感人。为什么？因为领域术语、长文本、复杂推理超出了它的能力圈。比如医学文献里的“该药物未显著降低死亡率”和“该药物无效”，通用NLI模型可能判为中立，但领域专家知道这几乎是蕴含关系。

再说向量相似度。这是最坑的。新手一看“语义向量”这四个字就觉得高大上，拿来直接做幻觉检测。来看个真实伤害案例：

上下文：“公司决定取消2024年的年终奖发放。”
模型回答：“公司2024年的年终奖照常发放。”

这两句话语义完全相反，但关键词重叠度依然很高（公司、2024、年终奖、发放），向量相似度可能还是很高。你要是信了相似度，就把严重幻觉给放过了。

反过来也一样：

上下文：“公司决定取消2024年的年终奖发放。”
模型回答：“2024年员工不会收到公司的年终奖金。”

这两句完全等价，但向量相似度未必比上一句高多少。所以单靠向量，你根本分不清“忠实改写”和“恶意篡改”。

最后是Judge LLM。新手最大的误区是觉得“只要GPT-4出手，就稳了”。结果一来成本爆炸，二来你会发现GPT-4自己也会幻觉，用“幻觉的裁判”去判“幻觉的运动员”，这画面太美。而且如果 prompt 设计不好，Judge LLM会过度严格，把合理的总结推理都打成幻觉；或者过度宽松，漏过明显编造。

正确的姿势是打组合拳，并且量力而行。

对于轻量级、实时的检测需求，用领域适配的NLI模型。不要用通用BERT，找一找有没有在你领域上微调过的模型，或者自己拿几百条数据微调一个。NLI特别适合做句子级别的忠实性判断。

具体做法是：先把模型回答拆成原子陈述。所谓原子陈述，就是把长句拆成不可再分的事实单元。比如“系统支持A功能和B功能，但不支持C功能”，要拆成三个陈述：1. 系统支持A功能；2. 系统支持B功能；3. 系统不支持C功能。然后每个陈述都去和对应的上下文片段做NLI判断。只要有一个陈述被判为Contradiction，整个回答就标记为存在幻觉。这样你不仅能知道有没有幻觉，还能定位到具体是哪句话在撒谎。

对于向量相似度，我的建议是：别单独用它做幻觉检测，可以用在检索召回阶段，或者作为NLI的辅助特征。比如相似度极低时，可以直接标记为“高度可疑”，然后送给Judge LLM做二审。

对于Judge LLM，它是目前综合效果最好的终审法官，但要用对。首先，prompt里必须给出清晰的判断标准和输出格式。最好要求它输出结构化JSON，比如包含 has_hallucination、type、evidence、confidence 等字段。其次，要加 few-shot 示例，告诉它什么算幻觉、什么不算。比如合理的同义改写不算，基于上下文的简单推理不算，但凭空添加数字和专有名词算。最后，Judge LLM不要放在主链路同步调用，走异步旁路。

来看一张兵器谱流程图：

这套组合拳的成本和效果最平衡。NLI做苦力，Judge LLM做考官，人工做终审。

小结：自动检测没有银弹，NLI、向量、Judge LLM各有各的舒适区。组合拳打好了，才能既省钱又准。

---

4. 量化评估体系：从二元判断到连续分数

检测出来有没有幻觉只是第一步，更关键的是怎么量化。你不能每次汇报都跟老板说“我感觉模型有时候在瞎编”，你需要数字，需要指标，需要能画成折线图的东西。

在RAG幻觉检测里，量化体系通常分为三个层级：系统级指标、样本级指标、Token级指标。

系统级指标看整体。比如 Hallucination Rate，就是被判别为包含幻觉的样本数除以总样本数。再比如 Serious Hallucination Rate，只统计那些会误导用户的关键事实错误。

样本级指标看单个回答的质量。最核心的是 Faithfulness，通常取值0到1。计算方式可以是对回答进行原子陈述拆分后，被上下文支持的陈述占比。比如回答里有5句话，3句被直接支持，1句是推理得出，1句找不到依据，那忠实度可能是0.8。另一个是 Answer Relevance，虽然它主要衡量答非所问，但答非所问有时候也伴随幻觉。

Token级指标则更细粒度，关注模型生成时的内在不确定性。比如回答中某些实体词的生成概率极低，或者困惑度在特定片段突然飙升，这些都可能是幻觉的早期信号。

新手在量化上，最容易走两个极端：要么太粗糙，要么太花哨。

太粗糙的典型，是只算一个“准确率”。你拿100条测试集，模型答对了90条，你就说准确率90%，幻觉率10%。但这个数字掩盖了太多真相。那10条幻觉是全是严重错误，还是只是措辞偏差？是集中在某个领域，还是均匀分布？你根本不知道。更可怕的是，有些回答虽然“对”，但其实是模型蒙对的，或者靠预训练知识而不是靠上下文答对的，这在严格意义上也属于RAG忠实性缺陷。

太花哨的典型，是滥用传统NLP指标。有人用 BLEU、ROUGE 来评估幻觉，这是完全走错片场。来看个让人血压升高的案例：

标准答案：“该产品采用Type-C接口充电，内置5000mAh电池。”
模型回答：“本产品配备了USB-C充电端口，搭载了一块容量高达5000毫安时的锂离子聚合物电池，续航表现非常优秀，可轻松满足一整天的高强度使用需求。”

如果你算ROUGE-L，这个回答分数可能非常高，因为关键词大量重叠。但实际上，模型额外添加了“锂离子聚合物”、“续航表现优秀”、“轻松满足一整天”这些上下文里没有的信息。这些信息可能是模型预训练知识的泛化，也可能是编造。在RAG场景下，如果上下文没提，严格来说你不该加戏。但ROUGE只会告诉你：“写得真棒，重叠率真高。”

另一个坑是Faithfulness计算里的“支持度”判定太粗暴。有些同学直接拿字符串包含来判断陈述是否被支持，结果把同义改写都判成了不支持，导致忠实度虚低。

要建立一套分层的、鲁棒的量化体系。

首先，系统级指标不要只看一个幻觉率，要分维度统计。你可以画一张饼图，看看幻觉都集中在哪些类型：

这张图一目了然，能告诉你优化优先级。如果45%都是忠实性幻觉，说明你的生成环节对上下文利用率低，优先修 prompt 和增加上下文压缩策略。

其次，样本级Faithfulness计算，一定要用语义级别的支持判断，不要用字符串包含。推荐的做法是：对每个原子陈述，用NLI模型判断它与最相关的上下文片段的关系。如果是Entailment，记1分；如果是Neutral，记0分；如果是Contradiction，记负分并加重惩罚。然后加权平均。RAGAS框架里就是这么做的，它会对每个陈述去匹配context中的支持句，最终算出忠实度分数。

另外，引入“来源可追溯性”指标。不仅要知道有没有幻觉，还要知道回答里的每句话来自哪段上下文。如果能建立这种细粒度的引用关系，用户甚至可以点击回答里的脚注去查看原文，这能极大降低幻觉的负面影响。

Token级指标虽然难以直接用于用户-facing的评分，但在离线分析时非常有价值。你可以用那些开源的、能输出logits的模型，分析在生成实体词时的概率分布。比如模型要生成一个日期“2024年3月15日”，如果“15日”这个token的概率分布非常平坦，或者概率值突然掉到0.01以下，那它很可能是在“硬编”。这时候你可以设计一个规则：对于实体类token，如果其生成概率低于阈值，就触发“高不确定”标记，并在前端给出提示“该信息置信度较低，建议人工核实”。

最后，量化指标一定要和人工评估对齐。每隔一段时间，抽样一批自动打分的样本，重新走一遍人工审核，计算自动指标与人工判断的皮尔逊相关系数。如果相关系数掉了，说明你的自动量化模型该重新校准了。

小结：量化不是为了在PPT上画好看的图，而是为了精准定位病灶、衡量优化效果，让幻觉从“玄学”变成“数学”。

---

5. 工程化落地：检测Pipeline与持续监控

前面学的都是“功夫”，现在要上场“打架”了。如何把幻觉检测从 Jupyter Notebook 搬到生产环境？怎么让它在真实业务流量里持续运转，而不是每次都手动跑脚本？

工程化落地的核心有三块：离线评估体系、在线监控告警、反馈闭环迭代。

离线评估体系，指的是每次你更新了模型、换了 prompt、调整了检索策略，都要在固定的测试集上跑一遍幻觉检测，看指标是涨了还是跌了。这是发布前的门禁。

在线监控告警，指的是生产环境里，用户真实query进来，你不能等用户骂你了才知道出事了。要在旁路对流量做采样检测，一旦发现某段时间幻觉率飙升，立即告警。

反馈闭环迭代，指的是把线上发现的 badcase 自动回流到标注池和训练集，持续优化你的检测模型和RAG链路本身。

新手在工程化上踩的坑，那真是“一步一跪”。

第一个坑，是把检测逻辑耦合在主链路里。你在RAG主流程里同步调用Judge LLM做幻觉检测，用户问个问题，本来2秒能答完，现在要等10秒。体验直接崩盘。而且一旦检测服务挂了，主链路也受影响，这属于架构设计事故。

第二个坑，是日志打得太粗糙。用户反馈“这个回答不对”，你回头去查日志，发现只记录了模型最终输出，没记录当时的检索上下文、没记录模型用的 prompt、没记录召回的Top-K文档。你想复现当时的幻觉现场，根本做不到。这在排查问题时是致命的。

第三个坑，是缺乏自动化的反馈通道。用户就算发现了幻觉，也只能在群里@你，或者填个冗长的反馈表单。反馈数据没有结构化入库，无法形成训练数据。三个月后，你手上还是那几百条旧测试集，系统遇到新问题依然抓瞎。

先聊架构。检测必须走异步旁路。主RAG链路保持轻量，快速返回答案给用户。用户的请求日志进入消息队列，由下游的检测消费组来处理。

这个架构里，NLI模型可以做同步的轻量初筛，延迟很低，对高置信度幻觉直接标记。复杂的Judge LLM评估放异步队列慢慢处理。

再说日志。RAG的日志必须“全链路可追溯”。每次请求至少要记录：用户Query、召回的Top-K原始文本、拼接后的Prompt、模型生成的原始输出、最终展示给用户的答案。有了这些，当你发现幻觉时，才能精准定位是检索丢包、排序错误，还是生成不听话。

然后是监控看板。你要画出几条核心曲线：实时幻觉率（过去1小时滚动窗口）、各类型幻觉占比趋势、高风险领域Top10（比如发现“财务报销”类问题的幻觉率远高于“IT支持”）。一旦发现异常波动，比如幻觉率从5%突然跳到15%，立刻触发企业微信或钉钉告警，相关人员介入。

最后是反馈闭环。在产品前端加一个“此回答有误”的按钮，用户一点，就把当前问答对标记为疑似幻觉，直接进入人工复核队列。复核确认后，这条数据同时做两件事：第一，加入Ground Truth测试集，用于下次离线评估；第二，作为难例去微调你的NLI检测模型，或者用于RAG链路的Few-shot示例库。久而久之，你的系统会越用越“抗骗”。

工具链选型上，离线评估强烈推荐 RAGAS，它对Faithfulness、Answer Relevance等指标有现成的实现。RAGAS适合离线批量跑分，它对每个样本都会调用LLM做评判，成本不低，所以不适合在线实时。在线可观测性可以用 TruLens，它能帮你追踪每个请求的检索和生成细节，非常适合调试阶段。如果你是在线服务，且对延迟敏感，建议自己用轻量模型搭建一个检测服务，配合缓存机制，把常见query的检测结果缓存起来，减少重复计算。如果你需要更轻量的，也可以基于 LangChain 或 LlamaIndex 的回调机制自己封装一个检测中间件。

小结：幻觉检测的真正价值，不在于抓住一次撒谎，而在于建立一套持续进化的免疫系统，让你的RAG应用在真实世界里越磨越锋利。

---

写在最后

写到这，估计你对RAG幻觉检测已经心里有谱了。咱们再唠叨两句。

做RAG的同学，最容易陷入一种“Demo幻觉”——看着本地跑的那几个漂亮回答，就觉得天下太平了。但做工程的人都知道，上线只是开始，用户千奇百怪的问题、文档里暗藏矛盾的角落、模型那天马行空的创造力，都会在你的系统里埋下一个个“胡说八道”的雷。

幻觉检测，本质上是在给AI系统装一个“质检仪”。从人工评估的Rubric，到NLI和Judge LLM的组合拳，从Faithfulness的量化打分，到旁路异步的监控Pipeline，这一套组合拳打下来，你才能真正睡个安稳觉。

这条路没有捷径。你可能需要反复校准你的自动指标，可能需要蹲在那些枯燥的 badcase 里找规律，可能需要在成本和效果之间反复权衡。但每一次你定位并修复了一个幻觉，你的系统就离“值得信赖”更近了一步。

编程之路不易，AI之路更难。但每一步扎实的成长都算数。保持好奇，保持怀疑，既要相信技术的力量，也要对技术的边界心存敬畏。你不仅能搭出酷炫的Demo，更能做出经得住考验的产品。

加油，咱们下回接着聊！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》