当你理解这一点的时候，就能理解所谓的模型就是一个概率机器——同样的 Prompt 会产生不同的答案。这也就带来了我们常说的幻觉问题。
而目前，解决幻觉问题最通用的方法就是 RAG。RAG 通过结合检索系统和大模型生成能力，来弥补纯生成模型的不足。它的大致原理是从向量数据库等系统中找到与用户问题最相关的信息片段，然后再把这些片段当成输入，一起喂给大模型。
比如问“2025 年新能源车补贴政策”，RAG 会检索最新文件，并让它来辅助大模型回答问题。由于有了更准确的上下文信息，而非只是依赖模型过时知识，所以，大模型生成的答案也就能一定程度上避免了凭空编造。可以这么说，RAG 的能力直接影响了大模型输出质量的好坏。
现在，随着大模型应用深化，RAG 技术也在不断发展。最新的 RAG 架构是组件化 RAG（Modular RAG），传统 RAG 像一位只懂机械检索的图书管理员——你问“新能源汽车”，他只能按字面意思扔出几本书，如果书单漏掉关键证据，那也束手无策。
而 Modular RAG 更像是一支高效协作的学术团队：检索专家从多角度找书（关键词、语义联想、知识图谱），过滤员剔除低质内容，逻辑顾问串联不同领域的证据链。它能够灵活调兵遣将，每个环节相对独立，具备了“查缺补漏”的能力。百度用的就是这个 RAG 架构。
数据层面，百度作为全球最大的中文搜索引擎，过去积累了非常海量的数据、知识图谱、知识库以及实时数据整合能力等。这部分能力中，有些可以复用，有些则需要调整。比如对于大语言模型而言，人类易读的搜索结果内容却不便于模型对内容抽取和理解。
于是，在既有的技术框架和模块化 RAG 架构的基础上，百度打造了一套可以处理搜索需求和大模型检索增强需求的 AI 原生的检索系统 AIAPI，它可以为模型生成提供更优质检索结果，并且兼顾资源利用率、响应速度和运行效率。不得不说，百度在 AI 技术方面的积累，真的让人敬佩。确实是一家认真做技术的公司。
第一，在召回和排序层，AIAPI 基于流量、接口控制参数，提供了多个套餐组合，这样需求方可以根据自己的场景定制最合适的套餐组合。非常灵活。
第二，数据层的主要功能是对不同的流量来源做不同路由控制和数据加工。AIAPI 通过使用图引擎实现对不同流量的隔离和定制化数据处理。同时增加网页内容获取的能力，添加对结果类型的筛选和数据组织能力。
第三，因为搜索产品的前端数据渲染和大模型完全不一样，所以把展现层拆分为了用户数据渲染和 AIAPI 数据接口。这样解耦后，AIAPI 又能够提供基于用户的鉴权、流控、特征管理等能力。
以上，我说的只是冰山一角。如果你在做 RAG 相关的落地，那我强烈推荐你看看百度技术团队的这篇文章。从技术架构图上我们能够看出来，百度把大模型和搜索放到了一个整体的框架之下，该复用的复用，该独立迭代的独立迭代。正因为大模型和搜索是联合优化的，所以，文心一言在专业性比较强或者小众的需求上也能够表现得比较出色。
比如，我问文心一言和 Kimi 同样的问题，你看看区别。问题是：“持中国护照去塞班旅游需要签证吗？可以的话，请提供相关资料。”其中，第一个截图是文心一言，第二个是 Kimi。从截图你能感受到，文心一言的回答更具结构性，言简意赅的把我需要知道的信息全部列了出来。
（Kimi 的回答）
（Kimi 的回答）
（Kimi 的回答）
说到底，大模型拼到最后，技术的较量是根本。
