从零搭一个Financial RAG Demo服务，听上去像是调几个包、写几十行代码就能跑起来的事。但真正动手之后你会发现，把一份财报PDF从"上传"变成"可问答的结构化知识"，中间每一个环节都有暗坑。今天这篇就从头到尾拆一遍我实际做出来的RAG服务，重点聊那些文档里不会写清楚的选型理由、调试思路和踩坑过程，希望能给正在做类似项目的朋友省点时间。
--- ## 1. 项目全貌：我到底在搭一个什么样的RAG服务 ### 1.1 从文件到答案的完整链路 先把我最终落地的服务形态描述清楚。一个最小的Financial RAG Demo服务，本质上是把四段逻辑串成一条流水线： 1. **摄取**：读取财务文档（PDF、Word、Markdown、CSV），做文本抽取与清洗。 2. **切分**：按语义或长度把长文本拆成块（chunk），每块自带元数据。 3. **检索**：用户提问时，用向量相似度（或混合检索）召回最相关的若干块。 4. **生成**：把召回的块作为上下文，交给大模型组织答案，并要求答案严格基于上下文。 我用一个极简的服务骨架说明这四段逻辑是怎么捏在一起的。下面这个例子基于Python的FastAPI实现，向量库用轻量级的SQLite+VSS扩展，不引入重型分布式组件，方便Demo演示和二次改造： ```python # app/main.py from fastapi import FastAPI, UploadFile, File from pydantic import BaseModel from rag.ingestion import Ingestor from rag.retriever import Retriever from rag.generator import Generator app = FastAPI(title="Financial RAG Demo") ingestor = Ingestor() retriever = Retriever() generator = Generator() class AskRequest(BaseModel): question: str top_k: int = 4 class AskResponse(BaseModel): answer: str sources: list[str] @app.post("/ingest") async def ingest(file: UploadFile = File(...)): doc_id = ingestor.process(file) return {"doc_id": doc_id, "status": "indexed"} @app.post("/ask") async def ask(req: AskRequest): chunks = retriever.retrieve(req.question, top_k=req.top_k) answer = generator.generate(req.question, chunks) return AskResponse(answer=answer, sources=[c.doc_id for c in chunks])注意，我故意把ingestor、retriever、generator三部分拆成独立模块。原因很实际：在Demo阶段，三个环节会以完全不同的频率被修改。切分策略调整只动ingestor，检索参数只动retriever，提示词迭代只动generator。如果一开始就揉成一团，后面每次调优都需要把所有代码重新梳理一遍。
1.2 这份Demo适合谁、解决什么问题
很多朋友听到"RAG"第一反应是想办法跑一个LangChain或LlamaIndex官方示例。我的建议是：如果你只是想验证RAG的核心机制，完全可以先用框架；但如果你是想在财务文档这种强专业领域做可控的问答，一定要理解每一层在做什么，否则出了问题根本不知道该调切分、该调检索还是该调提示词。
这个项目适合四类人：
- 想体系化理解RAG各环节原理，而不是只会调包的初学者；
- 需要在公司内部做财务知识库问答PoC的开发者；
- 做审计、尽调、财报分析辅助工具的产品原型设计者；
- 已经在用某些商业知识库产品，但想搞清"它背后大概怎么做"的评估人员。
它解决的核心问题非常聚焦：把"散落在多份财务文档里的信息"变成"能按问题检索、按上下文生成答案"的结构化服务。它的边界也很明确——不做财务数据实时行情解析，不做复杂财务计算引擎，不承担合规审计结论。那些都是另一个量级的系统。
1.3 技术选型的核心权衡：做Demo不等于做生产系统
我在选型时给自己定了三条原则：本地能跑、可解释、易替换。下面是最终选型及理由：
| 环节 | 选型 | 为什么这么选 |
|---|---|---|
| API框架 | FastAPI | 异步支持好，自动生成OpenAPI文档，调试问答接口非常方便 |
| 文档解析 | PDFPlumber + PyMuPDF | PDF是财报主力格式，两个库配合能处理表格和文本混排 |
| 切分 | 递归字符切分 + 段落锚点 | 财务文档结构稳定（章节、编号、表格），比纯长度切分好很多 |
| 向量化 | 本地Embedding模型 | 避免外呼API，保证Demo可复现、可断网运行 |
| 向量存储 | SQLite + sqlite-vss | 数据即文件，无运维负担；百万级以下Demo规模足够 |
| 生成模型 | 本地大模型 / OpenAI兼容接口 | 接口层抽象，方便切换不同型号 |
| 编排 | 手写轻量逻辑 | 核心代码不到千行，方便逐行讲解和改造 |
这个选型表看起来平淡，但每个选择背后都对应一个我踩过的坑。比如PDFPlumber和PyMuPDF，单独用谁都有问题：PDFPlumber处理表格坐标很准，但对扫描版PDF无能为力；PyMuPDF能处理文本层，但表格结构经常乱。两个配合起来，覆盖面才够。这些细节我在后面章节会展开。
2. 文档解析层：财报PDF怎么处理才不丢信息
2.1 两类PDF的分岔路径
财务文档的PDF来源基本分两类，处理逻辑完全不同。
第一类是数字原生的PDF，也就是从Word、LaTeX、排版软件直接导出的。这类PDF自带文本层，PDFPlumber可以直接抽取文字和表格坐标，处理速度快，准确率也比较高。
第二类是扫描版PDF，本质是图片集合。这类PDF没有文本层，必须走OCR管线。我一开始天真地以为只需要调一个OCR库就行，结果发现财报扫描件的版式复杂度远超想象：表格线、页眉页脚、多栏排版、印章遮挡，都会让OCR结果出现大量结构性错误。
所以我在ingestor里写了一个最朴素的判别逻辑：先尝试抽取前几页的文本层，如果每页有效字符数接近于零，就走OCR分支。判别代码很简单，但能省掉后续大量脏数据：
def is_scanned_pdf(path: str) -> bool: with fitz.open(path) as doc: for page in doc.pages(limit=5): text = page.get_text().strip() if len(text) > 50: return False return True注意，这个阈值为50个字符是经验值，OCR分支成本高、速度慢，所以阈值宁高勿低。如果前几页有文本层但后面是扫描页（混合文档），我的策略是逐页独立处理，保留每页的文本来源标记，后面做切分时用这个标记决定该页走什么清洗规则。
2.2 PDFPlumber与PyMuPDF的配合套路
拿到文本层的PDF之后，我常用的流程是先用PyMuPDF做一次整体文本提取，速度很快，适合拿到全文概貌；再用PDFPlumber针对"看起来像表格"的区域做精细提取，因为财报里真正有价值的数据往往在表格里。
判断"哪里像表格"也有窍门。我用的是一套启发式规则：如果某个页面里words对象存在明显的x坐标聚类，且同一y坐标上出现多条竖线，基本可以判定为表格区。这个规则写出来很简单，但识别准确率在财报场景里能到八成以上：
import pdfplumber def extract_tables(page): tables = [] try: table_settings = { "vertical_strategy": "lines", "horizontal_strategy": "lines", "snap_tolerance": 3, } tables = page.extract_tables(table_settings) except Exception: pass return tables为什么要强调vertical_strategy和horizontal_strategy都用lines而不是text？因为财报表格的框线比较规范，用线来对齐单元格比用文字推断可靠得多。反过来，有些公司财报有"开口表格"（表格线不全），这时候lines策略会漏数据，我一般是先按lines提取，失败再退回text策略，形成一个两段式回退。
处理过程中我还有一个独立实验结论：不要把PDF解析结果直接灌进向量库，必须先做基于规则的清洗。否则你会把页眉里的"XX股份有限公司年度报告"和页脚里的页码、公司网址全部作为语义内容入库，前后文检索时这些噪声会反复被命中，让top_k召回里混入大量无效信息。清洗规则我维护了一个小列表，优先级从高到低：
- 删除连续重复的页眉页脚行（可用正则或模拟指纹匹配）；
- 删除页码、页脚日期、网址（保留但不索引）；
- 把表格单元格内的换行符替换为竖线分隔符，避免切分时把一个单元格拆成两半；
- 对明显的"标题编号 + 标题文本"做规范化，比如把
3.2.1 合并利润表归一成一条标题记录。
这里多说一句关于OCR场景。如果文档确实需要OCR，我建议用可本地部署的开源方案，走"版面分析+OCR"的管线，优先做版面区块分类，再对每个区块单独识别，千万不要整页直接丢给OCR。这个建议在扫描版财报场景里特别重要，因为整页识别会把表格线误判成字符、把页眉页脚混进正文，后续切分质量会急剧下降。
2.3 内容抽取的验证与追踪
很多人做到"能抽出文字"就认为文档解析完成了，这是经验不足的典型表现。我现在的做法是，解析完一份PDF后，立刻生成一份"解析体检报告"，包含：总页数、各页字符数、表格数、疑似乱码段落数、页眉页脚命中数。这份报告不进入向量库，而是落到一个审计目录里。
这样做的好处非常直接。你之后发现某个问题怎么都检索不到正确内容，或者生成答案明显缺了一半数据时，先去查这个文档的解析体检报告，大概率能定位到是表格抽丢了、还是某页字符数为零不小心走了奇怪分支。这个习惯帮我节省了大量排查时间。
体检报告的代码骨架大致长这样：
@dataclass class ParseReport: path: str page_count: int chars_per_page: list[int] table_count: int scanned_flg: bool warnings: list[str]把warnings设计为列表而不仅是布尔标记，也是经验之谈。比如"第3页表格结构异常""第7页疑似乱码"，这类半结构化信息对后续调试的定位价值，远大于一个"ok": false。
3. 切分策略：为什么"按固定长度切"在财务文档上不靠谱
3.1 财务文档的结构特征决定了切分方式
财务文档和普通网页、技术手册相比，有非常鲜明的结构特征：多层编号体系（如 1.、1.1、1.1.2）、大量表格、定义了专业术语的章节、以及贯穿全文的交叉引用。这些特征直接影响切分策略的优劣评判。
如果采用最常见的固定长度切分（比如每500字符一刀切），会出现三个典型问题：
- 表格被从正中间切断，一行数据的两半散落在两个chunk里，检索时无论哪一半都难以还原语义；
- 章节标题和正文被人为分离，比如
3.2 重要会计政策这个标题在第一块末尾，而具体内容全在第二块开头，语义严重割裂； - 同一术语的定义和首次出现位置被拆开，导致后续检索命中"术语本身"却无法命中"术语解释"。
我在项目中采用的切分策略是：以段落锚点为主、固定长度兜底的混合切分。具体来说，先把全文按章节编号（正则匹配^\d+(\.\d+)*\s+.*）和空行划分出"自然语义段"，再对过长的语义段按句边界或列表边界做二次切分。这样得到的chunk能保证大多数情况下一个chunk内就是比较完整的语义单元。
3.2 切分参数的经验区间
切分问题没有一个标准差万能的答案，但经验区间是存在的。我的初始参数是chunk_size=800、overlap=120，单位是字符而不是token。为什么不用token？因为财务术语和表格里的数字串，tokenizer切出来的计数和人类可读字符数完全不成比例，字符数对调参更直观。
overlap=120这个值也不是随手填的。它是根据我的Embedding模型的有效上下文窗口推算出来的——过大浪费窗口，过小又让跨chunk的上下文无法衔接。后来我把这个值做成配置项，然后做了一组最小检索回归测试来标定：
| 参数组合（size/overlap） | 召回命中率（自定义测试集） | 生成的引用完整性 |
|---|---|---|
| 500/50 | 82% | 经常缺后半段 |
| 800/120 | 93% | 基本完整 |
| 1000/200 | 91% | 完整但chunk过大，检索噪声上升 |
这个结果表明，chunk大小对检索质量并非越大越好。太大的chunk让Embedding的语义被稀释，多个主题混在一起后，向量平均化的结果是哪个主题都不突出。800字符配合120字符的overlap，在我的测试集上表现最均衡。
3.3 保留元数据：表格、页码、章节路径
切分之后，每个chunk还必须携带元数据。我现在要求每个chunk必须包含以下字段：
{ "doc_id": "年报_2024_第3节", "chunk_id": "年报_2024_第3节_0007", "page": 23, "section_path": ["财务报表", "合并利润表"], "table_ref": "TBL-12", "content": "..." }为什么需要section_path？财务问答里用户经常问"第几节提到的XX"这类问题，如果chunk里没有章节路径，生成阶段就不可能准确回答"哪个章节说了什么"。table_ref则用于支撑"请展示表格原始数据"这类高可信度查询。
元数据在检索阶段的价值同样关键。我实现的检索器在向量相似度之外，还会用元数据做一次硬过滤。比如用户问"2024年第三季度的营业收入？"，检索器会先用正则或轻量意图解析提取年份和季度，然后过滤掉那些doc_id或元数据里不包含对应时间范围的chunk。这一步让召回结果的精确率提升非常明显。
4. 向量检索与混合检索：Embedding之外还要做什么
4.1 纯向量检索的局限性
做一个纯向量检索的Demo很容易，几条代码就够。但在财务文档这种对准确率要求苛刻的场景里，纯向量检索会暴露几个明显问题：
第一，数字和术语的相似度不可靠。比如用户问"毛利率"，向量上可能与"净利率"非常接近，但二者在财务上是不同科目。第二，否定语义容易失效。"不是流动负债"和"流动负债"在语义上相关，向量检索会把后者作为高相关结果召回。第三，表格数据的精确匹配不够。用户问"应收账款期末余额是多少？"，向量检索可能召回一个内容相似的段落，但无法精确断言某个数字来自哪一行。
所以我采用了一个不复杂的混合检索方案：向量检索为主、关键词检索为辅、结果做加权融合。关键词检索用词频和BM25这类简单算法就够了，不需要引入复杂搜索引擎。融合时，我给向量相似度0.7权重、BM25分数0.3权重。这个比例同样是回归测试标定出来的，如果财务领域里术语精确性更重要，可以适当调高BM25权重。
4.2 混合检索的实现细节
我用SQLite存储了一个倒排索引表作为BM25的数据源。它的结构不复杂：
CREATE TABLE inverted_index ( term TEXT NOT NULL, doc_id TEXT NOT NULL, chunk_id TEXT NOT NULL, tf REAL NOT NULL, df INTEGER NOT NULL ); CREATE INDEX idx_term ON inverted_index(term);每次ingest时，我把chunk做分词并统计词频，写入这张表；查询时，对用户问题做同样的分词，取出每个term的倒排记录，再按BM25公式计算分数。
这个实现看起来简陋，但好处是每一步都可审计：你能清楚地回答"某个term命中了哪些chunk、命中的原因是TF还是IDF"。这在调试时非常有用。我印象最深的一次问题是，"为什么用户询问某子公司的经营情况时，总是把母公司的营收也召回回来？"后来排查发现，是因为两家公司名称在文本里经常并列出现，倒排表里母公司名和子公司名的共现权重太高，融合时把这类噪声段推到了前排。定位到原因后，我在关键词检索加权里增加了一个"停用并列词"的规则，问题立刻缓解。
融合之后，会得到最终待生成上下文。我并不会把Top-K全部灌给生成模型，而是做一次重排（re-rank）：用轻量级的规则型打分器，对候选chunk做更精确的相关性排序。Demo阶段我用规则型重排就够了，规则包括：是否命中问题的年份、是否命中财务科目、是否位于section_path上层章节。这一套做下来，效果提升远比换一个更强的大模型明显。
4.3 检索质量的评估方法
要说这段经历里最值得分享的，可能是"怎么判断检索到底好不好"。
我给项目设计了一套最小可行的评估集：50个财务问答对，按来源文档类型归类（年报、财报附注、审计意见、董事会报告），每个问题标注"必须在哪个chunk中能找到依据"。每次改动切分、检索或重排逻辑后，我就跑一遍这个评估集，记录三个指标：召回率（答案依据是否被检索到）、精确率（前5个结果里有用比例）、以及生成引用完整率（生成答案是否引用了正确的来源信息）。
这个评估集规模不大，但价值极高。Demo阶段最忌讳的是"看着某个case对了就以为系统好了"，50个覆盖主要文档类型的case能帮你快速发现回归问题。我后来把评估集跑成一个脚本，接入到每次代码修改后的自动检查流程里，任何改动如果让召回率下降，我都会优先处理而不是继续加新功能。
5. 生成提示词与引用溯源：让大模型在财报上"老实回答"
5.1 提示词的目标是限制而非放飞
生成阶段，大模型的自由度是一把双刃剑。在财务场景里，模型自由发挥的危害远大于收益。一个不严谨的财务答案可能看起来非常合理，但数字引用错了小数点，后果是很严重的。
所以我设计的提示词核心目标是：约束模型只能基于检索回来的上下文作答，禁止外推任何财务结论。下面这段提示词是经过多轮迭代后的稳定版本，你可以直接抄：
你是财务文档问答助手。请严格基于<上下文>中的内容，回答用户问题。 要求： 1. 如果<上下文>没有直接依据，明确回答"在已有文档中未找到相关信息"，不要推测。 2. 涉及数字时，必须引用上下文中的原始数值，不要进行口算或近似。 3. 回答时给出信息所在的章节或表格编号，便于用户回溯。 4. 可以概括和重组语言，但不得新增上下文之外的财务观点。 <上下文> {context} 用户问题： {question}注意第2条和第3条。**"不要口算"**是我踩过坑之后加进去的。有一次模型把两个科目的数值自行相加，得出一个上下文里没有的"合计值"，表面上看起来很正常，实际上那个合计根本不在财报里，一旦被当成参考资料引用就出大事。第3条"给出章节或表格编号"则让生成结果天然具备可溯源能力，用户拿到答案可以直接回原文档核对。
5.2 引用溯源：不只是一行小字
很多人把引用溯源理解为"在答案末尾贴一个来源文件路径"。这太初级了。我实现的引用溯源是三层结构：
- 答案正文内的标记：在关键数字或结论后面加入
[S3-7]这样的标记，指代chunk_id或章节路径； - 回答末尾的引用列表：列出模型实际依赖的chunk及其元数据（文档名、页码、表格编号）；
- 溯源视图：返回
context_chunks完整内容，让前端可以展示"看这一段原文"的抽屉。
这样设计带来的用户体验是完全不同的。用户不再需要盲目信任模型输出，而是可以点击引用直接看到原文段落，自己判断模型说得对不对。对财务、审计类使用者来说，这个"可点击的信任"几乎是刚需。
我把溯源信息封装在响应结构里：
{ "answer": "根据合并利润表（见表格TBL-12），2024年度营业收入为12.3亿元[S3-7]。", "citations": [ { "chunk_id": "年报_2024_第3节_0007", "page": 23, "section_path": ["财务报表", "合并利润表"], "table_ref": "TBL-12", "snippet": "营业收入 1,231,456... " } ] }5.3 防止"幻觉引用"的几个实用规则
模型在生成引用时，还有一个隐藏风险：它可能"编造"一个看起来合理的chunk_id。因为大模型本质上在预测下一个token，引用的路径也可能被预测出来。我做了三件事来抑制：
- 给模型提供完整的
chunk_id列表和对应的章节路径，而不是只给内容文本；这样它更容易选择真实存在的引用目标。 - 在提示词里明确说：如果引用了某chunk，必须在引用列表中原样输出该chunk的ID，不得改写格式。
- 回答后过滤器校验：把模型输出的所有引用ID与真实chunk ID做精确匹配，不存在的标记自动删掉。
第三条是最终的兜底防线。语言模型再聪明，也可能在长上下文里出错，但程序化的精确匹配不会。这个过滤器大概30行代码，但它能拦截掉不少"凭印象引用"的问题。
6. 服务化落地：接口设计、错误处理与性能实测
6.1 接口语义与状态管理
Demo服务虽然小，但接口设计仍要遵循"语义清晰"的原则。我把核心操作拆成三类接口：
POST /ingest：上传文档，解析、切分、向量入库，返回文档ID和解析状态；POST /ask：发起问答，返回答案、引用列表和耗时；GET /health：返回服务运行状态、模型是否加载、索引中的chunk数量。
有人可能会问，为什么ingest是同步的而不是异步任务？在Demo规模下，文档量不大，同步处理能简化实现，也方便用户直观看到处理日志。但如果文档量大或需要并发上传，就必须改成任务队列模式。我在代码注释里留了迁移点，把ingestor.process(file)替换为job_queue.enqueue()即可。
接口层面还有一个容易忽略的问题：错误码语义。当用户上传一个损坏的PDF时，接口返回422还是500会直接影响前端处理逻辑。我的约定是：参数校验失败返回422，向量库写入失败返回503，模型加载失败返回500，并在错误体中携带stage字段告诉调用方是哪个环节出了问题。这个小小的约定在联调阶段帮我少吵了至少三次架。
6.2 性能实测数据
跑通后，我用三份不同规模的测试文档做了性能实测。文档A是单页表格型利润表，文档B是30页的年报摘要，文档C是200页完整年报加附录。测试环境是普通笔记本（CPU推理，无GPU），本地部署Embedding模型和生成模型。结果如下：
| 操作 | 文档A | 文档B | 文档C |
|---|---|---|---|
| 解析+切分时间 | 1.2s | 18s | 约3分钟 |
| 向量化+入库时间 | 0.8s | 6s | 约40s |
| 单次问答端到端耗时 | 约4s | 约5s | 约6s |
| 峰值内存占用 | 0.9G | 1.8G | 2.6G |
单次问答端到端耗时主要卡在生成模型推理上，CPU跑本地模型大约3~4秒，向量检索和重排几乎可以忽略。如果你用云端模型接口，这部分会很快，但会引入网络延迟和数据隐私问题。财务数据外发问题在真实场景中是绕不开的议题，Demo阶段我刻意选择本地部署，就是为了把所有环节都留在本地环境。
6.3 最大并发与资源占用的经验值
我压测用的简单方法不是上重型压测工具，而是用locust开少量并发用户跑几次/ask。实测结果：CPU推理模式下，同时5个并发问答请求会让单次响应时间从4秒劣化到9秒左右，超过10个并发时延迟会急剧上升，接近不可用状态。这个表现符合CPU推理的预期，也说明Demo服务适合小范围内部试用，不适合直接扛生产流量。
如果你确实需要更高的并发，我建议从两个方向改：一是把生成模型切成更小的量化版本，二是引入缓存。缓存这一点我在很多RAG Demo里看到被忽略得厉害——其实财务问答里大量问题是重复的（比如总是问"去年营收多少""净利润多少"），对同一问题的答案做短期缓存，可以显著降低模型推理压力。我实现了一个简单的key-value缓存，key是"问题+TopK召回chunk的指纹"，TTL设为10分钟，实测能把重复问答的响应时间从4秒降到50毫秒以内。
7. 调试经验分享：三个让我印象深刻的故障定位过程
7.1 症状：答案总是引用了错误子公司数据
某个测试case里，用户问某子公司的当年净利润，系统给出的却是母公司的汇总数字，而上下文里明明包含正确的子公司利润表。单看某个case，似乎只是"检索排序不够好"。我开始按这个方向调重排权重，调了两天效果都不理想。
后来我决定不猜了，直接打印检索返回的Top10 chunk标题。一看才意识到问题出在文档解析阶段：子公司的利润表在PDF里是一张表，表格第一列是科目名，第二列才是数据，但因为PDF解析时表格线检测失败，整个表被当作一个连续的文本块抽取出来，科目名和数据混在同一个cell里。向量相似度自然把"母公司汇总净利润"这种措辞类似的段落排到了前面。
这个案例给我的教训是：调试RAG系统，先查数据流水线，再怀疑检索排序。文档解析阶段的结构丢失，会以"检索效果差"的形式表现出来，让你误以为是检索算法的问题。
7.2 症状：对"上年同期数据"类问题回答混乱
用户问"上一年同期营业收入是多少"，系统有时引用当年的数据，有时引用今年数据。这个问题让我反复调了好几天，直到我仔细审视切分之后的chunk内容才发现：财报里经常在同一段话里同时出现"本期"和"上期"两个数字，甚至同一表格里左右两列就是两个报告期的数据。我的切分逻辑把这两列完整保留在一个chunk里，模型面对两个数字时，没有可靠依据判断哪个是"上一年同期"。
这个问题本质上是时间语义过滤不足。我后来在重排阶段加入了"问题年份识别"：先提取问题里出现的相对时间词（去年、上年同期、本期），再映射到具体的报告期，然后过滤掉不匹配的chunk。对于同时包含两个报告期的表格chunk，我再加一条提示词规则，要求模型优先使用与问题中相对时间词一致的列。这一改，这类问题的准确率立刻从六成提升到九成以上。
7.3 症状：大量问题返回"未找到相关信息"
有一段时间系统频繁返回"未找到相关信息"，我以为是检索recall不够，开始盲目调大top_k、增加overlap。后来发现，真正的问题是我在清洗阶段把很多表格数据按"表格线规范化"规则处理时，把单元格内的竖直分隔符误当成了普通字符，导致大量chunk看起来是"一行字符串"，嵌入后的语义严重损坏，检索自然命中不了。
这也再次验证了同一件事：在RAG系统里，脏数据导致的问题，都是用检索效果指标来报警的，但根因永远在更上游的解析和清洗环节。所以我现在每次收到"检索效果差"的反馈，第一反应永远是去抽查chunk内容，而不是急着调整算法参数。
8. 后续展望：从Demo走向真实财务场景
8.1 替换重型检索组件的路径
如果这个Demo要在真实项目里继续生长，第一件事是替换检索存储。SQLite加VSS在百万级chunk以内没有大问题，但超过这个规模，查询性能和平滑扩展性都会成为瓶颈。到时候可以平滑迁移到支持向量索引的专用数据库，或引入独立向量服务组件。
替换的关键点是维护同样的数据抽象。我一开始就把retriever.retrieve()的输入输出定义得很薄，只依赖question和top_k，内部存储细节完全隔离。这意味着换存储后端时，业务代码几乎不用动。这个设计意识，比选哪一个具体组件更重要。
8.2 从问答到分析：添加计算逻辑
财务领域的需求不会止步于"找到原文"，更多是"基于原文做计算"。比如用户问"销售费用占营业收入的比例是多少"，这需要一个可靠的数值计算引擎来处理，而不是让大模型口算。未来我计划加入一个轻量的数值计算层：从chunk里通过结构化抽取识别出科目和金额，再调用明确的计算函数，最后把计算过程附在答案里。
这样做的原因是，财务计算的可审计性要求很高。模型口算的"约等于"结果，无法用于任何正式场景。只有把计算的每个步骤都显式化，才能让用户独立验证。这一步改造会明显提升系统的实用价值，也是我认为RAG在财务领域真正落地的关键方向之一。
8.3 权限与分级：真实部署绕不开的课题
最后，如果系统真的要给财务团队内部使用，权限控制必须在服务层做起来。不同角色对文档的可见范围不同，普通员工能看部分年报摘要，管理层能看到全套附注。RAG服务需要在上游解析阶段就给chunk打上访问级别标记，在检索阶段根据用户角色过滤结果，在生成阶段还要避免引用用户无权访问的chunk。
这条我没在Demo里完整实现，因为复杂度会翻倍。但我建议任何打算上真实场景的人都提前设计访问控制的字段架构，不要等服务上线再补——因为一旦chunk在库里成型，权限字段的补录和重新切分的成本非常高昂。
我现在的实际体会是，做一个看似简单的"Financial RAG Demo"，真正消耗时间的不是写代码，而是反复打磨解析、切分、检索和生成之间的协作关系，并在每个环节建立可观测性。如果你也想动手搭一个，我的建议很直接：先别急着加功能，先把一条文档从上传到生成的完整链路打通，然后打印出每个中间环节的真实输出，亲眼看到数据在每个阶段长什么样。这一步做完，你对RAG的理解会比看十篇教程都深。
