> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI产品，光有数据还不够 - URL: https://www.hubwiz.com/blog/data-alone-is-not-enough-for-ai-products/ - Published: 2026-06-08T01:06:18.000Z - Updated: 2026-10-13T15:46:07.000Z - Description: 你的 AI 在读错东西：来自企业 AI 赋能前线的经验教训 - Author: admin - Tags: AI, #Import 2026-10-14 14:41 有一种特定的企业 AI 失败不会主动宣告自己。 你已经完成了上游工作。语义层已经文档化。定义已经治理。知识图谱将实体连接到关系，方式与你的业务实际运作一致。数据管道将干净、结构化的信息输入到一个按理说应该产出有用答案的系统中。 **AI 仍然会出错。** 没有错误触发或警报启动。输出流畅、自信，并且引用了真实的文档。但它在重要的方面是不完整的，而且直到有人基于它采取行动之前，没有人会发现这个问题。 这就是检索问题。它位于你的数据和你的模型之间，是大多数 AI 产品经理不将其视为产品决策的最关键层。 在这篇文章中，我们将从产品角度探讨检索的含义、它在 AI 工作流中的位置、如何设计规格来管理检索，以及如何验证检索机制。 ## 1、模型读取的内容 当用户发送查询时，模型不会读取你的整个数据资产。它读取的是一个由检索到的文档和数据片段组装而成的上下文小窗口。检索增强生成（RAG）就是决定什么内容进入那个窗口的架构模式。 这意味着什么很直接。你上游投资的一切：定义组织内部术语含义的语义层、将客户连接到合同再到政策的知识图谱、使这些定义可访问的数据管道——只有检索能将其浮现出来时，才能到达模型。 > ***"你的输出受限于检索返回的内容。"*** 这就是为什么两个具有相同底层数据的系统可以产生截然不同的答案。模型不是变量。检索层才是。 ## 2、问题和答案之间发生了什么 大多数团队将检索视为一次单一的查找。它实际上是三个阶段，每个阶段都有自己的决策，模型只在最后出现。 ### 阶段一：塑造查询 在问题触及任何文档之前，系统可能会重写或扩展它，将"SAR 截止日期"这样的短语转换为几种等效形式，以改善搜索的结果。 然后，查询被转换为文档存储可以搜索的数值表示。可以将其理解为将问题翻译成一种衡量含义而非仅仅衡量关键词的格式。进行这种翻译的嵌入模型是一个产品决策，它决定了问题能多好地映射到回答它们的文档。 ### 阶段二：查找和过滤 翻译后的查询搜索文档存储，但不是盲目搜索。过滤器首先运行，将搜索范围缩小到正确的文档：活动的策略文件、正确的领域、当前版本。如果没有这个关卡，查询会浮现恰好使用"截止日期"这个词的文档。 过滤后的搜索返回最匹配的文档片段。然后，重排序器根据这些候选片段回答问题的完整程度进行排序，而不仅仅是根据它们听起来有多相似。这一步决定了规则及其例外是一起被浮现还是被分开。 ### 阶段三：组装和回答 排名最高的片段被排列成模型实际读取的文本窗口。模型根据组装的上下文生成答案，输出验证层在响应到达用户之前运行。 ![RAG 系统如何找到正确答案](https://www.hubwiz.com/blog/content/images/2026/06/rag-system.jpg) RAG 系统如何找到正确答案 产品决策存在于所有三个阶段中，而不仅仅是最后的模型中。大多数团队只指定了模型，其余的全部移交。这正是差距形成的地方。 ## 3、一个做了所有正确事情的团队 考虑一个中型金融机构的合规团队：这是来自我专业领域金融的一个场景，但它直接映射到医疗、法律和保险中的监管工作流程。 他们构建了一个 AI 助手，帮助分析师回答关于内部 AML 政策和监管指导的问题。语义层很扎实：术语已定义、所有权已分配、词汇冲突已解决。底层策略文档准确且最新。 助手回答了一个常规查询：*我们的 SAR 申报截止日期是什么？* 公司的 AML 政策有两个相邻的章节。 - 第 4.2 节："*公司必须在识别出符合条件的交易后 24 小时内提交可疑活动报告。*" - 第 4.3 节："*例外：低于 10,000 美元报告阈值的交易遵循 72 小时的申报窗口，需经主管签字确认。*" 助手回答：24 小时。它引用了策略文档的第 4.2 节。引用是真实的，因为文档确实存在。但答案在操作上是不完整的，一个在错误上下文中基于此行动的分析师将面临合规风险。 #### 发生的事情与模型无关，也与数据无关。 策略文档是使用固定大小的分块方式摄取的：一个默认设置，不考虑内容结构地将文档分割成连续的 500 token 片段。 分块边界落在第 4.2 节和第 4.3 节之间。**检索返回了与查询相似度最高的片段**。该片段包含了 4.2。第 4.3 节从未被浮现。 ![AML 政策分块边界失败](https://www.hubwiz.com/blog/content/images/2026/06/chunking-failure.jpg) AML 政策章节的分块边界失败 ## 4、三个决定出了什么问题 每条检索管道都反映了三个产品决策，无论团队是否有意识地做出这些决策。上述合规团队默认地做出了所有三个决策。 ### 决策 1：分块策略 固定大小分块在 token 数量边界处分割文档，对内容结构没有任何感知。一个规则和它的例外占据策略文档的相邻章节，正是因为它们属于一起。将它们分开会产生一个检索表面，其中规则存在，但管理它的条件不存在。 2024 年发表在 NAACL Findings 上的一篇同行评审研究：[语义分块值得其计算成本吗？](https://www.vectara.com/blog/is-semantic-chunking-worth-the-computational-cost?ref=hubwiz.com)，由 Vectara 和威斯康星大学麦迪逊分校的研究人员完成，评估了 25 种分块配置在文档检索、证据检索和答案生成任务中的表现。 #### 研究结果比传统观点更加微妙：语义分块的优势高度依赖于具体任务，往往不足以证明额外计算成本的合理性。 更重要的是，分块配置对检索质量的影响与嵌入模型选择一样大甚至更大。分块是一个深思熟虑的设计决策，而不是一个基础设施默认值。 对于合规场景，感知章节的分块：在标题边界处分割，在分块元数据中保留章节编号，相邻章节之间有一个段落的重叠，可以将第 4.2 节和 4.3 节保持在一起。规则和它的例外会进入同一个上下文窗口。 ### 决策 2：查询-文档对齐 在分块决策之下有一个更深层次的问题，它解释了为什么即使正确的片段存在于你的文档存储中，检索也可能失败。 用户的问题和回答它的文本在向量空间中的嵌入方式非常不同。"我们的 SAR 申报截止日期是什么？"是一个问题。"公司必须在 24 小时内提交可疑活动报告"是一个陈述性策略声明。 通用嵌入模型将两者都转换为向量，但那些向量在衡量相似性的高维空间中并不会彼此靠近。 模型被训练来识别看起来相似的文本之间的相似性，而不是问题和回答它们的陈述性声明之间的相似性。 这就是查询-文档不对称问题，它存在于每条检索管道的底层。一个能完美回答问题的片段就坐在你的文档存储中，其向量与查询向量指向的方向略有不同。检索对它的排名低于一个恰好与查询共享表面词汇但相关性较低的片段。 有三种方法可以直接解决这个问题。 - **非对称嵌入模型** 专门在问题-文档对而非文档-文档对上训练的模型，使得查询向量和答案向量落在嵌入空间的兼容区域中。 - **查询扩展** 在嵌入之前将查询重写为多种形式：将"SAR 截止日期"转换为"可疑活动报告申报时间线"、"AML 申报要求"和"SAR 提交窗口"，然后用所有三种进行搜索。 - **HyDE：假设文档嵌入** 首先生成查询的合成答案，嵌入该合成答案而非原始问题，然后使用生成的向量进行搜索。合成答案看起来像文档文本，所以它嵌入后更接近文档文本。 对于合规助手，正确的组合是在监管问答对上微调的非对称嵌入模型，加上为不同策略文档和不同版本监管指导中出现术语变体启用的查询扩展。如果没有这些，当一个分块良好的文档包含正确内容但查询语言和文档语言不一致时，它仍然会被遗漏。 ![查询-文档嵌入不对称](https://www.hubwiz.com/blog/content/images/2026/06/embedding-asymmetry.jpg) 查询-文档嵌入不对称 ### 决策 3：为了完整性的重排序 单阶段检索返回语义上最相似的片段。它不返回最完整的答案。两阶段管道首先检索更广泛的候选集，然后在将上下文传递给模型之前按相关性和完整性进行重排序。 重排序器可以识别第 4.2 节和第 4.3 节引用的是同一个底层规则且具有条件关系，并将它们作为一个整体进行评分。单阶段检索没有这种逻辑。 对于部分答案会带来运营风险的工作流程，如合规、法律和财务报告，重排序是值得的。计算成本是真实的。浮现场规则而没有其例外的成本也是真实的。 ## 5、检索作为产品规格 在关于使企业数据 AI 就绪的文章中，我引入了上下文 YAML 作为捕获关于你数据的结构和语义事实的制品。同样的纪律适用于检索。 上述决策属于产品规格，而不属于工程默认值。当检索质量在模式变更、文档更新或嵌入模型版本升级后下降时，这个规格就是对照检查的基线。 ![检索产品规格](https://www.hubwiz.com/blog/content/images/2026/06/retrieval-spec.jpg) 这不是一个交接文档。它是决定模型能回答什么和不能回答什么的产品决策的记录。没有它，检索退化看起来就像一个模型问题，并被当作模型问题来处理。 ### 5.1 当答案存在于两个文档中 AML 场景之所以如此运作，是因为第 4.2 节和第 4.3 节存在于同一个策略文档中。更好的分块和重排序可以将它们一起浮现。当规则和它的例外在不同文档中时，结构性问题就改变了。 考虑同一场景的一个更难版本。24 小时的 SAR 申报要求存在于公司的内部 AML 政策中。10,000 美元阈值的例外存在于内部政策最后一次更新六个月后发布的 OCC 监管指导中。分析师问：*我们的内部 SAR 政策是否与当前的 OCC 指导一致？* 这个问题需要两件事：从内部策略检索相关章节，并从 OCC 文档检索相关章节，然后对两者进行推理。标准的单遍 RAG 对文档存储只做一次遍历。它浮现一个答案或另一个，而不是比较。模型永远不会同时看到两者，也无法浮现它从未获得的冲突。 这就是多跳检索，也是大多数合规、法律和财务报告工作流程最终要到达的地方。最重要的问题很少由单个文档回答。政策一致性检查、监管差距分析和跨司法管辖区的例外处理都需要跨文档边界进行推理。 ![单跳与多跳检索](https://www.hubwiz.com/blog/content/images/2026/06/multi-hop.jpg) 单跳与多跳检索 多跳管道分阶段运行检索。第一遍从主要来源检索最相关的片段：内部 AML 政策。模型读取这些片段并生成中间答案或澄清性子查询。 第二遍从次要来源（OCC 指导）使用中间输出来精确化搜索进行检索。然后管道将两遍的结果组装成组合的上下文窗口，模型跨它们进行推理以产生比较。 这里的产品决策与单文档检索不同。 管道需要一个路由层，在检索开始之前对查询进行分类：涉及比较、监管一致性或跨文档边界查找例外的问题路由到多跳分支。 它需要一个来源分类法，告诉管道每一遍应该搜索哪些文档存储。它还需要一个中间上下文层，将第一遍的输出携带到第二步检索中，而不丢失原始问题的线索。 对于合规团队来说，这意味着将一致性查询分类为多跳，将它们路由到一个在第一遍搜索内部策略、第二遍搜索监管指导的管道，并组装一个能同时浮现内部规则和外部要求的组合上下文。 如果没有那个架构，"*我们是否符合 OCC 指导？*"这个问题只能从内部文档得到回答。模型说是的。答案可能是错的。 ## 6、为什么检索失败是最难的一种 一个损坏的 API 会抛出错误。一个失败的数据库查询什么也不返回。糟糕的检索返回一些东西：流畅、格式化、有引用，而且语调正确。称之为完整性差距：输出看起来完整，引用了真实的来源，但以一种只有当有人采取行动时才变得明显的错误方式出错。 "这些错误可能比直接编造案例更危险，因为它们更加微妙，更难发现。" 斯坦福大学研究人员[研究了两个商用的基于 RAG 的法律研究工具](https://law.stanford.edu/publications/hallucination-free-assessing-the-reliability-of-leading-ai-legal-research-tools/?ref=hubwiz.com)，发现近五分之一的查询产生了误导或虚假信息，即使检索将模型建立在真实文档的基础上。 研究人员指出，引用级别的错误比直接编造更难发现：验证它们需要用户找到被引用的来源，阅读和理解它，并将其内容与模型用来支持的命题进行比较。大多数企业用户不会为常规查询这样做。 在斯坦福团队分析的幻觉响应中，47% 将朴素的检索作为促成原因，这意味着是检索层而非模型产生了错误答案的条件。模型从给定的上下文中正确推理了。上下文是不完整的。 这就是为什么检索质量需要自己的监控层，与模型质量指标分开。跟踪任务成功率告诉你输出是否好。它不告诉你检索是否是它们不好的原因。 这需要不同的检测手段：按文档类型的检索精度、多章节查询的片段命中率、文档或模式更新后的检索失败率。只监控模型输出的生产监控系统对大多数失败起源的层没有可见性。 ## 7、数据工作所假设的层 本系列之前的语义层文章涵盖了如何在企业数据中明确含义：定义、所有权和词汇冲突，它们决定了 AI 系统是否正确推理你组织的概念。知识图谱部分涵盖了如何将这些定义连接到它们描述的真实世界实体和关系。 两者都假设模型可以访问你构建的东西。检索是在查询时间使该假设成立或不成立的机制。一个结构良好的知识图谱配上一个损坏的检索管道，产生的答案与根本没有知识图谱一样不完整，因为模型永远不会看到相关的节点。 数据层工作创造了良好答案的条件。检索决定了这些条件是否得到满足。两者都值得产品级别的决策，被记录下来，并有记录的失败模式。 在你的技术栈中，检索是否曾是你没有预见到的失败点？ --- 原文链接：[The Retrieval Layer between Your Data and Your AI Outputs is a Product Decision](https://moderndata101.substack.com/p/the-retrieval-layer) 汇智网翻译整理，转载请标明出处 > **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)