用大模型做数据叙事，最爽的时刻是什么？输入一段数据，三秒钟后得到一段像模像样的分析文字——流畅、专业、像人写的。但最可怕的时刻往往紧随其后：你发现这段文字里有个数字跟原始数据对不上，或者某个"关键发现"根本不存在于数据中，又或者模型自信满满地引用了一个从未发生过的"趋势"。这就是大模型的幻觉——它像一个口若悬河但偶尔"脑补"的演讲者，说的每句话听起来都很合理，但你无法确定哪句是真、哪句是编。数据叙事的核心价值恰恰在于可信度，如果叙事内容本身不可靠，再漂亮的表达也是空中楼阁。解决这个问题的关键武器有两个：RAG（检索增强生成）和上下文学习（In-context Learning）。一个确保叙事"有据可查"，一个确保叙事"有样可循"。一、RAG：让大模型先查资料再说话
RAG 全称为 Retrieval-Augmented Generation，即"检索增强生成"。它的核心逻辑非常朴素：大模型在生成答案之前，先从外部知识库中检索相关的事实信息，把这些信息作为上下文注入 Prompt，再基于这些信息生成回答。用一个比喻来说：RAG 就像一场开卷考试。闭卷考试时，学生只能靠记忆作答，记错了就是错了（幻觉）。开卷考试时，学生先查阅资料，再基于资料作答——答案的准确性取决于资料的质量和查阅的能力，而不是背诵的运气。在数据叙事的场景中，RAG 的工作流程通常分为三步：第一步，构建知识库。将原始数据（结构化表格、非结构化文本、知识图谱等）切分成适当大小的片段，通过 Embedding 模型转化为向量，存入向量数据库。这一步决定了"资料库"里有什么。第二步，动态检索。当用户提出叙事需求时（比如"分析这家医院 2024 年运营效率的变化"），系统将用户需求也转化为向量，在数据库中检索最相关的数据片段。检索不是简单的关键词匹配，而是语义相似度匹配——即使你的查询词和数据片段的字面表述不同，只要语义相近，也能被召回。第三步，增强生成。把检索到的数据片段作为上下文，连同用户的叙事需求一起输入大模型，让模型基于这些"参考资料"生成叙事文本。由于生成过程被检索结果"锚定"，模型编造的概率大幅降低。RAG 的价值不仅在于减少幻觉，更在于让大模型具备了处理私有数据的能力。通用大模型的训练数据截止于某个时间点，也不可能包含你单位的内部数据。RAG 通过外部知识库的接入，把大模型从"通才"变成了"专才"——它仍然不懂你医院的运营细节，但它懂得去查你提供的数据，然后基于查到的内容作答。二、上下文学习：用示例教会模型"怎么说"
RAG 解决了"说什么"（内容有据可查），但还没解决"怎么说"（叙事质量可控）。大模型的输出风格高度依赖 Prompt 的设计。同一个数据源，Prompt 写得不同，输出的叙事可能一个是干瘪的公报体，一个是生动的故事体。如何稳定地控制叙事质量？答案是上下文学习（In-context Learning）。上下文学习的核心思想是：在 Prompt 中提供几个符合要求的输入-输出示例，让模型从中"学习"任务模式，然后对新的输入生成同样风格的输出。这种方法不需要微调模型参数，只需要调整输入的文本——简单、灵活、即插即用。举个例子。假设你想让大模型生成一段"面向医院管理者的运营分析叙事"，你可以在 Prompt 中放两个示例：示例 1：数据：心内科 2024 年 Q1-Q4 平均住院日分别为 8.2、7.6、7.1、6.8 天。 叙事：心内科平均住院日在 2024 年呈现持续下降趋势，从年初的 8.2 天降至年末的 6.8 天，降幅达 17%。这一改善主要得益于临床路径优化项目的推进，特别是在 Q2 引入的术前评估标准化流程。建议下一步将这一模式推广至神经内科和骨科。
示例 2：数据：全院 2024 年门诊量同比增长 12%，但患者满意度从 92% 降至 87%。 叙事：门诊量增长并未带来患者体验的同步提升。数据显示，2024 年门诊量同比增长 12%，但患者满意度反而下滑 5 个百分点。深入分析发现，候诊时间延长和医患沟通时间缩短是主要痛点。建议在扩大接诊能力的同时，优化分诊流程和增加下午门诊时段。
给模型看了这两个示例后，再给它一个新的数据点，它就能按照同样的风格——"数据事实 + 趋势解读 + 归因分析 + 行动建议"——生成叙事。这就是上下文学习的威力：不需要告诉模型"请按以下格式写"，只需要给它看几个好例子，它自己就能模仿。三、双剑合璧：RAG 提供弹药，上下文学习校准准星
RAG 和上下文学习不是二选一，而是互补协作的关系。可以用一个射击的比喻来理解：RAG 是弹药供应系统——它确保你手上有准确的事实数据，不会在关键时刻"空仓"。没有 RAG，模型只能凭训练记忆中的"大概印象"作答，数据精准度无法保障。上下文学习是瞄准镜——它确保你打出去了能命中目标（符合要求的叙事风格和质量标准）。没有上下文学习，模型可能拿到了准确数据，却写成了学术报告的风格，而你的受众是医院管理者。首先，用 RAG 检索到相关数据片段。比如用户问"分析一下我院心内科最近一年的运营情况"，RAG 从知识库中检索出心内科的住院日、手术量、费用结构、并发症率等相关数据。然后，把这些数据片段和 Few-shot 示例一起组装进 Prompt。Prompt 的结构通常是：角色定义 + 任务说明 + Few-shot 示例（展示"怎么说"）+ RAG 检索到的数据（提供"说什么"）+ 待分析的新数据。最后，模型基于这个完整的上下文生成叙事。由于既有示例引导风格，又有检索数据约束内容，输出的叙事同时满足"有据可查"和"质量可控"两个标准。四、实践中的三个关键细节
要让 RAG + 上下文学习真正发挥作用，有三个细节需要特别注意：第一，检索质量决定一切。RAG 的输出不可能比检索到的输入更好。如果检索召回的数据片段不完整、有偏差或者与用户问题不相关，模型生成的叙事就会建立在错误的基础上。优化检索的方法包括：合理的数据切分策略（chunking）、多路检索融合（向量检索 + 关键词检索）、以及重排序（reranking）提升相关性。高质量的知识库建设是 RAG 的根基。第二，示例的选择要有代表性。上下文学习的效果高度依赖示例的质量。好的示例应该覆盖你希望模型掌握的各种叙事模式——趋势分析型、对比分析型、归因分析型等。示例太少或太单一，模型容易过度拟合；示例太多，又会挤占上下文窗口。实践中 3-5 个精心设计的示例通常效果最好。第三，留出"不知道"的出口。即使有了 RAG，也可能出现检索不到相关内容的情况。此时模型的本能是"硬编"——用训练记忆中的泛化知识来填补空白。在 Prompt 中明确加入约束："如果检索到的资料不足以支撑结论，请明确说明'根据现有数据无法判断'，不要推测。"这个简单的约束能显著降低幻觉风险。五、写在最后
大模型做数据叙事，最大的魅力在于效率——过去需要分析师花几个小时完成的分析写作，现在几分钟就能出初稿。但最大的风险在于可信度——你不知道这些文字里埋了多少"幻觉地雷"。RAG 和上下文学习正是为了解决这对矛盾而生。RAG 让叙事有凭有据，上下文学习让叙事有样可循。两者结合，才能既发挥大模型的生成效率，又守住数据叙事的可信度底线。在实际工作中，我建议从最简单的方式开始：先搭一个基础的向量数据库，把核心数据灌进去；再写 3-5 个符合你团队叙事风格的示例，固化在 Prompt 模板里。跑通这个最小闭环后，再逐步优化检索质量、丰富示例库、完善校验机制。大模型不会取代数据分析师，但会用好 RAG 和上下文学习的人，一定会比不会用的人产出更快、更准、更有说服力。
夜雨聆风
