过去两年，我们为受监管的金融科技客户交付了多套RAG系统——欺诈检测增强、合规文档问答、监管申报分析、内部政策助手。这些项目里有一个规律反复出现：大约90%的首个生产部署都会踩中相同的十个架构错误，而且踩坑顺序高度可预测。
这不是模型不行或工程师能力问题。交付这些系统的团队通常都很专业。错误是系统性的——公开RAG教程不会暴露它们，因为演示数据根本触发不了；厂商营销则主动掩盖，承认这些会削弱销售说服力。
如果你正准备在金融科技公司内部立项RAG，以下是我们建议在签署工作说明书前必须警惕的十个问题。
消费级RAG演示可以容忍5%的幻觉率、缺失的引用、缓慢的查询或陈旧的语料库。用户会重试、优化或离开。错误答案的经济成本只是一次稍差的会话体验。
金融科技RAG不能容忍任何一项。在受监管场景下，错误答案可能是审计发现、监管罚款、基于错误数据发放的贷款、遗漏的欺诈信号，或合规官在证词中朗读的笔录。错误答案的经济成本可达七到八位数，法律成本有时关乎存亡。
这改变了"好架构"的定义。主导需求不再是检索质量、延迟和成本（这些仍然重要，但优先级靠后），而是可追溯性、弃权行为、审计追踪和更新完整性。大多数公开RAG内容优化错了方向，因为它们为不同的威胁模型而写。
以下十个错误按出现频率和修复成本排序。
第一个错误是概念性的，它决定了后面九个是否会被当作问题对待。
朴素的RAG架构有三个盒子：摄入、检索、生成。大多数公开教程这么画，大多数工程团队这么定范围，大多数厂商演示这么展示。
生产级金融科技RAG至少有八个盒子，缺失的五个正是合规所在：
将金融科技RAG定为三盒子系统的团队，最终会在上线后被迫补装缺失的五个组件——当审计对话让它们的缺位暴露时。这种后补的架构脆弱且维护成本高昂。可追溯性故事不完整。合规官不满意。
如果你从本文只记得一件事：要定范围的是整个系统，不只是检索。我们在基础设施层有具体展开——参见我们的pgvector与Pinecone生产基准测试对比。
大多数RAG教程展示固定大小分块——512词元、1024词元、50词元重叠，然后上线。这在金融科技场景会失败，原因有二。
第一，监管文档有结构。招股说明书有章节层级，贷款协议有定义条款和契约条款，合规政策有生效日期和修订历史。固定大小分块会切断这些语义边界，导致检索返回跨章节碎片，生成器被迫缝合不兼容的上下文。
第二，引用粒度。审计要求你指向具体来源。如果分块跨越三个监管段落，你无法证明答案来自哪一段。我们见过团队因无法将生成内容映射到具体条款而在审计中受挫。
正确做法是基于文档结构的分块：按章节边界分割，保留元数据（文档类型、生效日期、版本），维护分块到原始段落的映射表。成本更高，速度更慢，但能通过审计。
第三个错误是假设向量搜索足够。在金融科技场景，大量关键信息不是语义可检索的——它是精确匹配的。监管文件编号、交易金额阈值、日期范围、实体标识符。这些需要混合检索：向量搜索处理概念查询，关键词搜索处理精确约束，结构化查询处理元数据过滤。
团队常在生产后才发现，30-40%的查询需要精确匹配组件，而他们的架构没有预留这个管道。重构检索层比一开始就设计进去贵五到十倍。
第四个错误是关于弃权。消费级RAG被训练成总有答案。金融科技RAG必须被设计成知道何时不说话。当检索置信度低于阈值、当来源冲突、当查询涉及训练数据截止日期之后的事件——系统需要明确返回"我无法基于可用文档回答"，而不是合成最可能的猜测。
实现弃权行为需要三个组件：检索置信度评分、来源一致性检查、时间边界感知。大多数首版部署包含零个。
第五个错误是更新完整性。金融科技的文档不是静态的。监管规则变更、政策修订、新判例出现。 naive 的"重新索引整个语料库"策略在数据量小时可行，在生产规模下会中断服务或耗尽预算。
需要增量更新架构：版本化文档存储、变更检测、影响分析（哪些已生成答案可能因这次更新而失效）。我们见过团队因无法证明模型在特定日期看到了哪版政策而被监管质询。
第六个错误是审计追踪的粒度。记录"用户问了X，系统回答了Y"不够。需要记录：检索到了哪些分块、它们的来源和版本、生成时使用的提示模板、模型版本、温度参数、任何后处理步骤。并且这些日志需要不可篡改，保留期限符合监管要求。
第七个错误是人工复核的集成点。高风险决策不能全自动。架构需要设计人工介入的触发条件（置信度阈值、敏感关键词、金额阈值）和复核工作流界面。事后添加这些会导致用户体验断裂。
第八个错误是测试覆盖。公开RAG的测试是"看起来对吗"。金融科技RAG的测试需要对抗性案例：边界查询、过时文档陷阱、矛盾来源、试图诱导违规建议的提示注入。我们维护的测试套件比生产代码还多。
第九个错误是运营监控。需要追踪的不是延迟和成本，而是检索失败率、弃权触发频率、人工复核比例、文档版本漂移。这些指标在消费级RAG不存在。
第十个错误最隐蔽：把RAG当作搜索增强。它不是。RAG是生成系统，生成系统有失败模式，失败模式需要治理。金融科技需要的架构是"可治理的生成"，不是"更好的搜索"。
这十个错误的共同点是：它们都不是技术难题，是范围界定问题。团队有能力解决，但只有在被明确要求时才会解决。而要求来自对监管环境的理解，不是来自技术教程。
如果你正在评估RAG厂商，问他们这十个问题。如果答案涉及"可以后期配置"或"不是标准功能"，你面对的是一个为不同威胁模型设计的系统。重新谈判范围，或更换供应商。
金融科技的首个RAG部署往往决定未来三年的技术债务方向。前期多花的两个月架构设计，能避免后期十八个月的补救工程。这个账不难算，但需要在立项时就有人算。
热门跟贴