RAG 在中文法律 / 财税
场景的工程现场。

检索增强生成——也就是 RAG——是过去两年被讲烂了的一个词。它的基本原理简单到一句话能说清：先从一堆文档里检索出相关片段，再把这些片段连同问题一起交给大模型，让模型基于这些片段作答。教程满天飞，开源框架现成。但当我们真的把 RAG 用到中文法律和财税这两个场景上，发现教程里那个干净的流程，几乎每一步都会出问题。这篇文章记录的就是这些「现场」——理论和落地之间那些没人写进教程的缝。

为什么挑法律和财税来讲。因为这两个场景把 RAG 的难度推到了极致：它们的文档极度专业、结构复杂、容不得半点错误，而且强依赖时效——一条法规、一项税收政策，去年有效今年可能就废止了。在这两个场景里，一个看起来能跑的 RAG 系统和一个真正可用的 RAG 系统，差着十几个具体的工程决策。下面分四个环节来说。

§ 01切分:法律条文不能从中间切开

RAG 的第一步是把文档切成片段。通用教程的标准做法是「按固定字数切，比如每五百字一段，段与段之间留点重叠」。这个做法在普通文章上还行，在法律和财税文档上是灾难。

法律条文有它自己的结构——编、章、节、条、款、项，层层嵌套。一个「条」是一个完整的法律意义单元，把它从中间切开，就像把一句话从中间切开一样，两半都失去了意义。更麻烦的是引用关系：法律条文里大量出现「依照本法第二十条规定」「前款所称……」这种句子，如果切分时把第二十条和引用它的那一条分到了不相干的两个片段里，检索时模型就只能看到半截信息。

财税文档更复杂。一份税收政策文件，正文之外常常带着附件、附表、解读、过渡条款，它们之间的逻辑关系密不可分。我们见过一个反例：某个 RAG 系统按固定字数切分一份增值税政策，把「适用税率」和「适用的前提条件」切到了两个片段，结果模型检索到税率片段就直接答了，漏掉了那个关键的前提条件——这种错误在财税场景里是要出事的。

所以我们做法律财税 RAG，切分这一步从来不用固定字数。我们做的是结构化切分：先解析文档的层级结构，以「条」或一个完整的政策要点为最小单元，绝不从语义单元中间切开；同时把每个片段所属的章节路径、它引用了哪些条款、它被哪些条款引用，全部作为元数据挂在片段上。这样检索到一个片段时，它的上下文坐标是完整的。

§ 02检索:专业问法和文档用词对不上

切分之后是检索。RAG 的检索通常依赖向量相似度——把问题和文档片段都转成向量，找最接近的。这个机制有个隐含假设：问题的表述方式和文档的表述方式，语义上是接近的。在法律财税场景里，这个假设经常不成立。

原因是专业领域存在严重的「问法和写法不一致」。用户问的是大白话——「公司请客吃饭的发票能不能抵税」，而税法文件里写的是「业务招待费税前扣除」。用户问「员工离职公司要赔多少钱」，劳动法条文里是「经济补偿金」「代通知金」。这种口语提问和专业术语之间的鸿沟，纯向量检索经常跨不过去——它们字面差太远，语义模型也未必能桥接。

我们的处理是两条。第一，检索前先做术语改写——在检索之前,用一个小模型把用户的口语问题翻译成专业术语,用专业表述去检索文档,召回率立刻提升一大截。第二,用混合检索代替纯向量检索——向量检索负责抓语义相关的,关键词检索负责抓那些字面精确匹配的（比如用户直接报了某个文件号或条款号),两路结果再做一次重排合并。法律财税场景里,这种混合检索几乎是必须的,因为这个领域既有大量需要语义理解的口语问法,也有大量需要字面精确命中的法条引用。

§ 03引用:答案必须能溯源到原文

第三个环节,是法律财税 RAG 区别于普通 RAG 最关键的一点——可溯源。在普通场景里,RAG 答得差不多对就行。在法律和财税场景里,「差不多对」是不能接受的:一个税务师不会因为 AI 说「大概是这样」就敢去做申报,一个律师不会因为 AI 说「我觉得」就敢写进意见书。他们需要的是:AI 给出的每一个结论,都必须能精确地指回它依据的是哪一部法、哪一条、哪一款。

这意味着 RAG 系统不能只输出一段流畅的答案。它必须做到:答案里的每一个关键论断,都带着可点击的引用,点开就是原文条款,而且能看到这一条所在的完整章节位置。换句话说,系统输出的不是「答案」,是「答案 + 它的全部证据链」。专业用户真正信任的、真正会用的,是那条证据链,而不是那段话本身。

这也反过来约束了前面的切分和检索:正因为最终要做精确溯源,切分时才必须保留每个片段的完整坐标,检索时才必须保证召回的是确切的那一条而不是邻近的近似条款。可溯源这个要求,是从输出端倒推回去、贯穿整个 RAG 链路的一条主线。

我们还做了一件事:让模型学会说「我不知道」。当检索回来的片段不足以支撑一个有把握的回答时,系统不允许模型硬编一个答案,而是明确告诉用户「现有资料库里没有足够依据,建议咨询专业人士」。在法律财税场景,一个诚实的「不知道」,远比一个流畅的错误答案有价值。一次自信的幻觉,可能就让用户做错一笔申报、签错一份合同。

§ 04时效:去年的政策今年可能已经废止

最后一个、也是最容易被忽略的环节——时效性。法律会修订,司法解释会更新,税收政策更是几乎每年都在变,大量政策还自带明确的有效期和过渡期。一个 RAG 系统如果只是把文档一次性灌进去就不管了,用不了多久,它就会开始一本正经地引用已经废止的旧政策。在财税场景,引用一条过期政策的危害,不亚于凭空捏造一条。

所以法律财税 RAG 不是一个「建好就完事」的系统,它是一个需要持续维护的系统。我们会在每个文档片段上标注它的生效日期、失效日期、被哪份新文件替代;检索时把时效作为一道硬过滤——默认只返回当前有效的条款,已废止的除非用户明确要查历史,否则不进入答案。同时,资料库本身需要有一套持续更新机制,新政策出来要能及时入库,旧政策失效要能及时标记。

这一点直接决定了项目的交付形态。法律财税 RAG 不该被当成一个一次性的实施项目交付,它更应该被当成一个需要长期持续运维的系统来设计——这也是为什么我们给这类客户的方案里,持续优化服务从来不是可选项,而是和实施本身同等重要的一部分。一个不更新的法律 RAG,它的准确率会随时间单调下降,半年后就可能从「有用」变成「有害」。

§ 05回到那个根本问题:为什么还要做

讲完这四个环节的难处,有人可能会问:既然法律财税 RAG 这么难,坑这么多,为什么还要做。答案是因为它的价值同样巨大。法律和财税的专业知识门槛极高、信息高度分散、查询又极其高频——一个税务师每天要查无数次政策,一个企业法务每天要翻无数遍条款。一个真正可靠的 RAG 系统,能把「查找和定位」这件占用专业人员大量时间的事大幅压缩,让他们把精力放回到真正需要专业判断的地方。

关键在于「真正可靠」这四个字。一个不可靠的法律财税 RAG,不仅没价值,还有负价值——它会用流畅的语气误导专业人员,而专业人员一旦被误导一次,就再也不会信任它。所以这个场景没有「先做个能跑的 demo 试试」的空间。它要么做到可溯源、有时效、敢说不知道,要么就不该上线。

这篇文章把切分、检索、引用、时效四个环节的现场都摊开了讲,不是为了说这件事有多难,而是想说清楚一件事:法律财税 RAG 的难度,不在大模型本身,而在围绕大模型的那一整套工程——怎么切、怎么检、怎么标引用、怎么管时效。大模型只是这套系统里的一个零件,真正决定它能不能用的,是零件之外的那些工程决策。这,就是 RAG 在中文法律财税场景的真实工程现场。