上个月，我和一位券商的朋友吃饭，他正带着一个内部的AI知识库项目。饭还没吃到一半，他就开始吐槽：Demo做出来的时候，领导挺兴奋，说终于可以把几十年的制度文件、研报、公告都管起来了。结果知识库一上生产环境，问什么翻车什么。问他投研报告里的某个数据，答非所问；问合规制度里某一条的具体要求，它给你编了一段；最离谱的是问一份产品说明书里的费率，直接给错了数字。
他最后总结了一句话——现在回头看，不是模型的错，是第一批数据就没弄好。
这句话我特别有感触。过去大半年，我陆陆续续帮几位金融圈的朋友看过类似的项目方案，也在几个团队里做过RAG落地的技术咨询。我发现一个特别普遍的现象：大部分金融行业的RAG项目，真正的失败点根本不在大模型选型，也不在Agent流程设计，而在最前面的数据准备和检索基建。用我的话说，就是死在了第一步。这个系列前面两篇聊的是AI基础和大模型应用的整体思路，今天这篇把焦点拉到RAG知识库本身，专门讲清楚那个让无数人翻车的“第一步”到底难在哪、该怎么迈过去。
1. 大多数金融RAG项目的典型死法：Demo惊艳，一上生产就废
很多团队对RAG项目的理解是：找一批文档，向量化，丢进向量数据库，然后接上大模型，一个知识库问答系统就出来了。在市面上的技术教程里，这套流程确实跑得通，三五个文档用LangChain或者LlamaIndex，几十行代码就能出一个效果不错的小Demo。但一到金融机构的真实环境，这套路径几乎必然失效。
1.1 金融文档的“体质”和通用教程里的测试文档不一样
通用教程里用的文档，大多是结构规整的网页文章、Markdown文件、说明手册，本身就是为阅读和解析设计的。金融行业的真实文档是另一回事，我这些年接触到的典型类型包括：
- IPO招股说明书、上市公司年报，动辄几百页，里面全是复杂表格和数字
- 内部合规制度文档，条款编号细到“第X章第X条第X款”，且不同条款之间频繁交叉引用
- 投研报告、行业深度，图文混排，图表是信息密度最高的部分
- 合同协议、产品说明书，对措辞精确度要求极高，一个“可”和“应”的区别在法律含义上是天壤之别
- 大量的扫描件、盖章件、传真件，本质是图片而不是文本
这些文档放进通用解析脚本里，第一个问题就是：PDF转出来的文本是乱的。表头对不上列，多栏排版读成一行，页眉页脚混进正文。如果你不做处理就直接切块向量化，那等于垃圾进、垃圾出。用户问出来的答案自然五花八门。
1.2 我反复看到的一个真实项目回放
我在帮一个团队做方案评估的时候，完整旁听了他们项目的翻车过程。他们选了公司最近三年的几百份研究报告，要做“研报智能问答”。模型用的是当时效果不错的通用大模型，向量库用的开源社区最常见的那套配置，Embedding模型也是社区的通用中文模型。Demo阶段选了二十几份质量比较好的报告，效果确实惊艳，问什么都能答。
上生产之后，问题接踵而至。先是用户反馈：问“某公司2023年营收”，回答里的数字是错的。技术排查发现，研报PDF里的表格被解析成了乱序文本，数字和年份对不上。再后来有人问“报告里对某行业的竞争格局怎么看”，模型只引用了摘要部分的内容，完全没有读到报告正文里有价值的分析段落。最后复盘发现，问题出在切块策略上，默认的固定长度切块把长段落拦腰斩断，语义完整的分析被切成好几片，检索时只召回了一部分，答案自然支离破碎。
这个案例特别典型，因为它不是一个孤立的实现问题，而是整条“文档解析—切块—向量化—检索—生成”链路在金融场景下全面暴露短板的过程。
1.3 “第一步”的边界到底划在哪
我所说的“第一步”，不是指启动项目时的需求分析，也不是指大模型API调用，而是从原始文档到“可以被可靠检索的索引”这整段链路。它至少包含五个环节：
- 文档格式解析：把PDF、Word、扫描件变成结构清晰的文本
- 版面结构还原：识别标题层级、段落边界、表格、页眉页脚
- 文档清洗与标准化：去掉干扰信息、统一格式、处理修订版本
- 切块策略：决定哪些内容应该作为一个整体被索引
- 向量化与元数据构建：决定用什么方式表达内容、如何过滤
这五步只要任何一环做得不扎实，后面接再强的模型也救不回来。因为RAG的核心逻辑是“先找到对的材料，再让模型基于材料回答”。材料本身就是错的，或者检索根本拿不到对的材料，模型只能一本正经地胡说八道。
2. 金融文档的“三座大山”：表格、扫描件和长章节结构
既然“第一步”的核心是数据工程，那第一步里最头大的问题是什么？我做了这么多项目，总结下来就是金融文档的三座大山——复杂表格、扫描件、长文档结构。这三类问题几乎覆盖了金融行业知识库建不好的所有根因。
2.1 表格解析：数字错位不只是难看，还会直接给错误答案
金融文档里表格是绝对的主角。财报里的三张表，研报里的财务预测，产品说明书里的费率表，合规文件里的限额表，全部是表格。而通用PDF解析工具处理表格的效果，说实话，大部分时候是灾难。
我用一个场景来说明：一份年报PDF里的“主要会计数据”表格，有三年对比数据，表头年份在顶部，第一列是科目名，后面几列是逐年数据。直接转成纯文本后，常常会出现两种问题，一是列顺序错乱，年份和数据对不上；二是跨页表格被截断，下半页的表头丢失，数据全部错位。
一旦表格解析错了，检索阶段是发现不了的，因为向量检索看的是语义相似度，数字错位在语义上几乎无感。但生成阶段就出问题了，模型根据错误文本生成了错误的财务数字，用户一旦拿去用，就是实打实的风险事件。
实操层面，我比较推荐的分层策略是这样：
- 简单规整表格（规则的行列结构），用pdfplumber或Camelot这类工具先试，识别成DataFrame再序列化
- 复杂表格（合并单元格、多级表头、跨页表格），优先考虑转成Markdown格式，保留层级关系
- 实在解析不了的表格，建议OCR加版面识别，或者人工介入，不要硬扛
我踩过最深的一个坑是：一个项目的表格解析准确率已经做到90%了，团队觉得够了，结果恰恰是那10%的错表全是用户最常问的高频问题。金融场景的容错率就是0，10%的错误率等于不可用。
2.2 扫描件与OCR：识别率只是及格线，版面还原才是关键
金融机构里有大量历史文档是以扫描件形式存在的。老合同的扫描版、盖章文件、传真件、早年间的监管报告，全是图片。很多项目直接用OCR跑一遍，把文字提取出来就进向量库，结果在召回层面表现极差。
为什么？因为OCR的重点不只是“把字认出来”，还要把版面结构还原出来。扫描件的标题在哪、正文在哪、表格在哪、页眉页脚是什么，这些信息直接决定了后续切块的质量。如果OCR只输出一行一行的裸文本，那文档的层级结构、段落边界全部丢失，切块时只能靠固定长度硬切，效果自然很差。
我建议的条件式方案是：如果扫描件比例超过总体文档的20%，就不要在技术选项里只用开源OCR方案了，要上带版面分析的OCR工具链，或者直接采买商业级的文档解析服务，把版面还原、表格识别、阅读顺序判定都做进去。金融行业文档一旦涉及扫描件，人工抽检这一环也必须加进去，机器处理过的每一批结果都要按比例抽几份做人工验证。
2.3 长章节结构：制度文件最容易被切碎
金融行业最典型的长章节文档，就是内部制度文件和监管法规。这种文档动辄上百页，章节、条款、附则层层嵌套。用户经常问的问题是“什么情况下可以提前终止合同”“反洗钱客户身份识别的触发条件是什么”。
这类问题的答案往往集中在一个具体条款里，而条款又依赖前置定义。如果切块策略不保留文档原有的层级结构，就特别容易把“定义”和“使用该定义的具体条款”切到不同的块里。检索时召回了使用条款的切片，但缺失了定义部分，模型回答时就缺少关键约束条件，轻则回答不完整，重则直接出错。
我的一个习惯做法是：在做切块之前，先给文档建一棵结构树。把标题、章节、条款编号全部解析出来，生成层级关系，然后以这个结构为边界做切分。整个制度文件最终会被切成“章—节—条”的层次，而不是一刀切的字符块。这个前置步骤看起来多花时间，但对后续的召回效果提升是决定性的。
3. 切块策略：人人都会切，但多数人没想过金融场景的“边界感”
切块（Chunking）是RAG项目里最容易被低估的一环。很多教程把它讲得轻描淡写：把文档按固定字数切开就行，500字一个块，重叠100字。但在金融文档上，这种粗放式切块基本等同于把一本精装书用剪刀乱剪一遍。
3.1 为什么固定长度切块在金融场景特别不灵
固定长度切块的问题是，它完全不关心文本的语义边界。同一个自然段里，前半段在讲营收增长的原因，后半段在讲未来风险提示，按500字一切，这两部分可能被塞进同一个块里，也可能被切到两个不同的块里。检索时如果只命中其中一块，模型就只能看到一半的上下文，回答的自然性、准确性都大打折扣。
更麻烦的是金融文档里大量的“定义条款”。一个金融术语的定义可能只有几十个字，它和后面数条引用它的条款之间有非常强的引用关系。固定长度切块根本意识不到这种引用关系，它会把一个定义条款和它前面的其他条款揉在一起，导致模型检索到的时候，上下文里全是无关信息。
3.2 三种能实际落地的切块方案对比
我自己试下来的实践感受是，下面三种方案在金融场景里最值得尝试：
递归字符切分是目前最常规的选择，LangChain里的RecursiveCharacterTextSplitter就是代表。它的逻辑是按段落、句子、字符逐级回退，尽量把完整段落保留在一起。适合内容规整、段落结构清晰的文档。优点是实现成本低，缺点是遇到复杂表格和跨页内容仍然会乱。
结构感知切分是我在金融场景下最推荐的方式。先识别文档的标题层级和段落结构，以“章—节—条—款”为边界切分。比如一个问答系统要回答“合同终止条件”的问题，结构感知切分可以保证包含了“终止条件”那个条款的完整段落作为一个块进入索引。这样召回到的不仅是一段文字，还是语义上自洽的一段完整信息。
语义切分是更进阶的方式，利用Embedding模型判断句与句之间的语义相似度，相似度低的地方就是天然的分割点。效果确实好，但计算成本高、耗时长，适合对质量要求极高、且可以接受较强算力开销的场景。金融行业如果预算允许，可以考虑切给核心业务场景用，比如投研问答、风控条款查询。
3.3 切块参数怎么定：有实验，才有发言权
很多团队问我说“chunk_size设多少合适”，我一般会反问：你的评估集准备好了吗？没有评估集，任何参数选择都是心理安慰。
切块参数不是一个纯拍脑袋的配置项，它应该通过一个简单的召回实验来验证。具体做法是：准备几十个真实场景下的问题，每个问题标注出应该命中哪些文档片段。然后用不同参数组合（块大小、重叠大小、切分方式）分别做检索，看哪个组合的召回率最高。这个实验本身不难，但绝大多数项目都跳过了这一步，直接按默认参数上线，之后所有效果问题都无法归因。
我做过的一个项目里，同一批制度文档，固定长度512字切分的召回率只有61%，换成结构感知切分后直接到85%。这二十几个百分点的差距，就是专业文档和通用文本在切块环节上的真实差距。
4. 检索召回：向量只是起点，金融场景要的是“查得准”
切完块、向量化之后，技术团队最常犯的第二个认知错误，是把“向量检索”当成了唯一的召回手段。通用场景里，向量检索用起来简单、效果也还行，但在金融行业，纯向量检索几乎一定不够。
4.1 纯向量检索的失效案例：条款号与数字查询
向量检索的本质是语义相似度匹配，它对“语义相近”敏感，但对“精确匹配”很不敏感。金融场景里恰好有大量精确匹配需求：
- “找一下2023年第7号公告的第三条”
- “某产品说明书里申购费率是多少”
- “关于反洗钱客户身份识别的第几条要求是什么”
这类问题里，条号、数字、费率这些关键信息，向量模型往往会“一视同仁”，把它们当作普通语义处理，结果是召回了语义相近但完全错误的文档。用户问了三次同样的精确问题，模型每次都给了不同的错误答案，这在金融业务里根本没法用。
4.2 混合检索加重排：金融RAG的标准配置
解决这个问题，我的经验是必须做混合检索。核心思路是：向量检索负责“语义召回”，关键词检索负责“精确匹配”，两者结果融合后，再过一层重排模型（Reranker）做精排。
关键词检索在金融场景的价值被严重低估。我用Elasticsearch或OpenSearch做BM25检索时，专门把条号、定义术语、专有名词作为词典权重放大。比如用户问“沪港通”相关的制度，BM25能通过精确匹配“沪港通”这个词把包含该词的所有条款全部捞出来，而向量检索可能会把“沪深港互联互通机制”“港股通标的股票”等语义相近但不完全一致的内容混进来。
重排模型的作用就更直接了。粗召回阶段可以让向量和关键词各取回50到100条候选，再用重排模型逐条打分，最后取Top5送进大模型。重排模型比普通Embedding模型更精细，能捕捉到“候选片段是否真正回答了用户的问题”这种深层语义关系。金融场景强烈建议选在金融语料上做过微调的重排模型，如果预算允许，用自己内部的历史问答数据微调一版，效果会明显好于通用模型。
4.3 元数据过滤：这个不起眼的环节最容易救项目
纯向量检索还有一个问题：它检索的是全部内容。但金融知识库是多源、多版本的系统，一个合规问题可能同时存在2021版、2022版、2023版三份制度。如果不做版本过滤，模型最常做的就是“学会”把最新的版本和旧的版本混在一起回答，因为它的目标是生成一个“像样”的答案，而不是一个“正确”的答案。
元数据过滤就是在检索之前，先把检索范围缩小到一个合理子集。比如先限定文档类型是“合规制度”，再限定日期在“2022年之后”，再限定机构是“公司总部”。这样召回出的结果天然就是符合当前场景的，大模型在受限范围内生成，准确性会高很多。
我给客户的标配是：每一篇文档入库时，至少要打上这几类元数据——文档类型、发布时间、发布机构、生效状态、适用业务线。这几个字段会救你很多次，尤其是当你的知识库文档超过一千篇之后。没有元数据过滤的RAG，到后期基本是灾难。
5. 八成团队跳过关键一步：质量评估体系应该先于效果优化
在我接触过的金融RAG项目里，有一个特别有意思的现象：项目上线前，大家关注的都是技术实现有多炫，模型效果在Demo里有多好；项目上线后，大家关注的变成了“为什么这个问题答错了”“为什么那个数据是错的”。所有人都想优化效果，但几乎没有人提前建立一套质量评估体系。结果就是项目一旦出问题，团队连定位问题的抓手都没有。
5.1 没有评估集，所有优化都是自欺欺人
评估集是什么？就是一组带标准答案的真实场景问题集。没有它，你就无法量化地回答这些问题：切块方案调整之后是好是坏？换了Embedding模型到底有没有提升？重排模型加进来之后误答率降了多少？
如果你回答不了这些问题，那你做的所有优化都只是在“感觉上变好了”。金融行业的项目是不能靠“感觉”交付的。我见过好几个团队，花了两三周调Prompt、换模型、调参数，最后发现效果自己心里都没底，上线后被业务部门一个刁钻问题问倒，整个项目直接被打回重做。
5.2 金融场景评估集怎么搭：三类问题缺一不可
我建议金融团队在项目启动的第一周就准备评估集，不需要很多，50到100条就够用。重点是要覆盖三类问题：
- 抽取型问题：答案直接来自文档的某个具体位置。比如“某公司2022年年报中经营活动产生的现金流量净额是多少”。这类问题考察解析和切块是否保留了关键信息。
- 归纳型问题：答案需要跨多个段落或条款综合得出。比如“根据合规制度，新客户开户需要提交哪些材料”。这类问题考察召回是否完整、是否跨块整合了信息。
- 条件判断型问题：涉及金融业务规则。比如“客户风险等级为高风险的，哪些业务必须做增强型尽职调查”。这类问题考察RAG在多条件和边界情况下的抗幻觉能力。
每类问题各准备二三十条，每条标注标准答案或答案来源文档位置。做完这一步，项目才真正有了一个可以迭代的基线。
5.3 一个让我印象深刻的评估“反转”案例
我给一个基金公司做评估方案的时候，发现他们团队用了一个很“自信”的优化步骤：把所有Embedding模型换成了当时评分最高的一个通用模型。Demo确实变好了。但等我用他们自建评估集一测，发现其中一个关于“某基金产品申购费率上限”的问题答错了。
排查后发现，那个新模型把“费率上限”和“费率下限”的语义距离算得很近，导致最终的检索结果里混入了一条关于下限的条款。模型基于混合结果生成，数字自然错了。后来我们在评估集里专门加了一类“数字敏感型问题”，并给检索流程加了数字约束规则，这个坑才算彻底填上。
所以那一次经历之后，我一直跟团队强调：不要用Demo效果代替评估指标，不要用一两次内部演示的顺滑度来衡量项目质量。只有在评估集上能稳定拿分的RAG系统，才有资格放到业务部门面前。
6. 能落地的路径，从文档盘点开始而不是从模型开始
讲到这里，你应该已经意识到一个问题：RAG项目的第一步，其实不是技术选型，而是文档物理层面的准备。能不能跑通，在你看完第一批文档的时候就大概有数了。
6.1 先用“文档抽样”算出改造量
不要上来就把整个知识库的文档一股脑全部入库。我的建议是：先抽样100份最具代表性的文档，按难易程度分个级。A类是文本层质量好、表格少的优质PDF，加工成本低；B类是表格较多、结构复杂的PDF，需要专门的表格解析；C类是扫描件或图片型PDF，必须走OCR流程。
抽样分级之后，你对整个项目的工程量就有了相对准确的预判。我在一个信贷文档项目里抽样时发现，C类文档占了接近一半，立刻建议客户把第一期的上线范围缩小到制度类和电子版来源的文档，扫描件放到二期专攻，项目才没有从一开始就陷入泥潭。
6.2 按文档类型分流，而不是一套流程打天下
很多项目失败的核心原因之一，是把所有文档看成同一种东西，用一种流程处理。金融知识库天然是多类型的，研报、制度、公告、合同、产品说明书，它们的解析重点和切块方式差别很大。
我现在的做法是：先按文档类型定义不同的解析管线。研报类走“版面分析+表格提取+段落切块”，制度类走“结构识别+条款切块+交叉引用保留”，合同类走“条款级拆解+风险等级元数据标注”。每类管线在入库前还有质量抽检环节，抽检不过就退回人工处理。听着重，但这对金融项目的长期稳定运行是必须的。
6.3 第一批用例要小，但必须打穿完整链路
最后一个建议是：第一批上线范围务必克制。宁可只做一个业务子领域的五十篇文档，也要把“解析—切块—索引—检索—生成—反馈修正”这条链路彻底打穿。
我在实施中最大的收获之一是，小范围打穿可以带来两样宝贵资产：一是经验，团队通过第一批五十篇文档走通了所有类型的坑，后续扩展到一千篇时，处理效率是指数级提升；二是信任，业务部门看到几个高频问题能被准确回答后，才会愿意配合后续的文档梳理和反馈标注，这批种子用户是整个项目活下去的根基。
7. 最后说说我自己的实操体会
如果非要用一句话总结金融行业RAG项目的要点，我会说：RAG不是“大模型能力”项目，而是“文档工程质量”项目。那些Demo惊艳的团队，多在模型上下足了功夫；那些生产环境稳定的团队，都在文档上下足了苦功。
我在做技术方案时也会反复提醒团队：用户不会问“这个PDF转出来的文本结构怎么样”，用户只会问“2022年年报里的营收是多少”。答案错一次，信任就没了，后面很难补回来。这也导致我现在做金融项目时，对数据环节的敬畏心远高于对模型环节的热情。
还有一个想强调的小技巧：一定要把“坏例子”当资产。每一次用户反馈的错误，都对应着整条链路上的一个具体缺陷，把它补进评估集，下一次迭代就有了方向。这比任何人拍脑袋想出来的优化点都可靠。
最后，如果你们团队正准备启动一个金融知识库项目，我的建议很简单：开工前，先把所有PDF打开看一眼，如果那些表格、扫描件、复杂版式让你心里发慌，那说明你要投入的精力比预想的要多得多。但换个角度想，这恰恰也意味着，一旦你把这块硬骨头啃下来，整个项目的护城河也就建立起来了。别人学走的是模型调用流程，你沉淀的是数据治理能力和对业务的真正理解，这才是金融场景里不可替代的部分。
