1. 为什么要做把小说装进数据库项目背景与目标拆解1.1 RAG 的典型动机不是跟风是文档太多没人看先说清楚——这个项目不是接了什么外包需求也不是公司安排的 KPI纯粹是我自己想验证一套 RAG 从零到一的完整链路于是把一本小说当作测试语料。为什么选小说第一文本量适中一本几十万字的小说足够撑起索引、分块、召回、生成全流程的压力测试。第二小说里的长对话、人物关系、场景切换天然考验 RAG 对上下文的切分能力比拿产品文档好玩得多。第三小说是典型的非结构化长文本和现实里知识库、合同、聊天记录的场景高度类似踩过的坑都有复现价值。RAGRetrieval-Augmented Generation检索增强生成解决什么问题一句话——大模型不知道你的私有知识。它训练时没见过你的小说全文你直接问它这本书里主角第三次逃婚时说了什么话它只能瞎编。RAG 的逻辑是先把小说拆开、向量化、存进数据库用户提问时先在库里做向量检索把最相关的片段捞出来再连同问题一起塞给大模型生成回答。检索质量直接决定回答上限这也是后面五个硬伤的根源。如果你完全没接触过 RAG可以把它理解成开卷考试。大模型不是闭卷背答案而是先给你一本可以翻的书数据库你翻到相关段落再照着书答题。翻书翻得准不准决定了答得对不对——这就是检索环节的命门。1.2 数据库选型为什么最终落在 SQLite 向量扩展上这一步很多人会纠结上 Milvus上 Weaviate上 Elasticsearch对于一个验证型项目我的选型逻辑很简单——机器配置一般、不想搭一堆依赖、随时想改结构那用 SQLite 加上向量扩展是下限最低的选择。实际我用的是 sqlite-vec 这套方案配合一个叫 dbx 的图形工具来调试数据。SQLite 本身是单文件数据库零部署备份就是拷贝一个文件。sqlite-vec 提供了 vss 虚拟表可以在 SQLite 里直接执行向量检索不需要启动独立服务。对于小说这种中等级别的文本量几十万字符它的召回速度完全够看毫秒级。如果你手上是千万级以上的文本或者同时跑几百路并发查询那我建议直接上 Milvus 或者 pgvector别在 SQLite 上死磕。但验证 RAG 流程、学习原理、测试不同分块策略SQLite 这个方案最不容易劝退新手。这也是我第一个 RAG 能快速跑通的关键原因。重要经验选数据库前先估算语料总量和查询频率。小说几十万字向量维度 512一条向量几百字节总共也就几百 MB 的库文件。这个量级用 SQLite 完全合理但如果一上来就搭 Milvus 集群维护成本反而把真正的 RAG 设计问题掩盖了。2. 五处硬伤的完整复盘从现象、根因到修复第一版完整跑通后我开始拿真问题测试结果相当难看。这里把五个硬伤按严重程度从轻到重列一遍每个都讲清楚症状、排查过程、根因、和最终处理。这样你以后再做 RAG就算不踩同样的坑至少能第一时间对症下药。2.1 硬伤一分块切坏了长对话和章节标题症状是——你问主角和第二主角在酒馆里聊了什么回答里出现了主角和配角的对话或者干脆答非所问。一开始我怀疑向量模型不行后来检索结果显示召回的前三条 chunk 根本不在同一个章节里。排查过程我是这样做的把小说按固定字符数512 字符切块每块之间留 64 字符重叠。问题就出在固定切块上——它可能切在段落中间甚至把一个人的完整一句话从中间切断那个 chunk 里的语义就变得非常碎片化向量和 query 的相似度自然不会高。根因很简单文本切分没有尊重文档的语义边界。小说的语义边界是什么章节、段落换行、对话人名。修复方式分三层第一层优先按章节标题切每个章节独立成块章节太长再按段落继续拆。第二层段落本身超过设定长度时用句号、问号、感叹号、省略号做二次切分避免切断一个完整句子。第三层对话密集的章节用换行符和人名冒号做切分锚点。修复后的效果立竿见影——章节内的对话问答召回率明显提高。这件事让我明白向量模型的底子固然重要但分块策略不对底子再好也白搭。2.2 硬伤二metadata 没建好检索结果像盲人摸象第二个问题更隐蔽。一开始我的 metadata 只存了文档 ID 和 chunk 序号没存章节号、章节标题、人物名单。结果检索出来虽然命中了正确章节但用户完全不知道这段内容来自哪里回答里也没有上下文锚点。更麻烦的是我在做过滤检索时无法按章节筛选。比如我明知道答案在第 8 章但系统仍然把所有章节的候选 chunk 都拉出来排序既拉低准确率又消耗生成上下文窗口。后来我在每条 chunk 的 metadata 里补了这几项chapter_no章节数字编号chapter_title章节标题characters该段落中出现的主要人物名预处理时用名单匹配start_char和end_char在原小说中的字符偏移方便回溯原文加了这些之后我在查询接口里支持了按章节号预过滤 向量排序的两段式检索。这样做的好处是RAG 不再只能做全文相似搜索而是可以像查论文目录一样先锁定范围再精读。2.3 硬伤三Embedding 模型上下文长度与小说长句的冲突小说里有一些人名拼写很长、专名多还有那种一口气几百字的长句。我的第一个 embedding 模型是当时很常用的all-MiniLM-L6-v2它的最大输入长度只有 256 token。长句被强行截断后后面的语义直接丢了——最典型的就是一句他冷冷地说后半段包含关键动作被截掉了。这里有个容易踩的误区不是所有 embedding 模型都能感知超长文本很多模型对超出上限的部分是直接截断而不是平均池化。你以为是模型懂全文其实它只看前 256 个 token。处理方案短语义优先切分时尽量让每个 chunk 不超过模型上限的 70%留出安全余量。换带长文档支持的新模型现在很多 embedding 模型支持 512 或更多 token价位也不高但一定要看模型的说明别贪便宜选过时的。双通道检索对于特别长的句子我尝试先生成句子摘要索引再用摘要去匹配 query最后映射回原文片段命中率会提升。实操心得选 embedding 模型时除了看 MTEB 榜单分数更要先看 max sequence length。很多本地部署的小模型适合短文本短新闻、问答一旦喂小说这种长句式文本效果直接崩。2.4 硬伤四Top-K 死值导致的多选题灾难与召回不全刚开始我把 Top-K 固定在 4想着召回 4 段应该够了。结果问复杂问题时比如主角离开家族后流浪了几年路上遇到谁最后为什么回来这个问题的答案分散在多个章节Top-K 只捞回了其中一部分大模型拿到不完整的上下文后只能编故事。反过来有些简单问题只分布在一个段落里Top-K 却硬拉了 4 段候选把不相关的内容也塞给大模型白白增加了回答里胡说的概率。这个问题的本质是Top-K 是固定的超参数但问题复杂度是动态的。我的改动引入动态 Top-K先设一个较大召回池比如 20 条再做 MMR最大边际相关性去重或者重排最后只保留 top 5。相关性阈值低于设定阈值的片段直接丢弃宁可召回少不要召回烂。问题类型感知把问题分成事实型、地点型、关系型、时间线型不同问题类型用不同的召回策略地点型加大重排权重时间线型增加按章节过滤。实际效果是回答的幻觉率明显下降尤其适合小说这种长文本中天然要串联多个章节才能回答的问题。2.5 硬伤五生成阶段上下文超长被截断回答虎头蛇尾最后一个硬伤最让人抓狂——检索召回质量没问题了但大模型的 context window 又炸了。小说这种文本动辄每个 chunk 几千字符我召回 5 个 chunk 就是三万字塞给本地小模型直接超限。模型只能吃下前面的内容后面的全被硬截断回答经常刚开始好好的说到关键处就戛然而止。这里必须明确一个概念检索召回的是证据不是全文迁就。不是把越多的原文塞给模型越好大模型的注意力会被稀释而且不同位置的内容权重不一样中间部分的语义最容易被挤压掉。我的处理方式压缩 chunk 粒度把单条 chunk 控制在 512 字符以内必要时把长段落切成多块但保留共享 metadata。按问题重排后再裁剪先做一次快速重排只挑出最相关的 2-3 个 chunk 进入生成阶段而不是全部塞进去。设定生成窗口如果模型支持 8K 上下文就设定生成窗口 6K把检索结果循环压缩到窗口内。经过这轮调整回答的完整率上来了尤其适合小说这种段落长、需要前后引用的文本。3. 从五个硬伤到五个教训为什么 RAG 工程比模型选择更关键前面复盘的是具体 bug这里我想跳出细节说说我做完整个项目后沉淀下来的方法论。这些东西不写在官方文档里但我实际试验下来每一条都能让 RAG 项目少浪费一周时间。3.1 教训一先设计 Chunking 策略再选 Embedding 模型别反着来很多人上来就挑最强的 embedding 模型然后随便按字数切一切就完事。但文本结构决定了切分质量乘上 embedding 质量才是检索质量的上限。对于小说必须按照章、段、句去切。对于产品文档可以按 Markdown 标题层级去切。对于聊天记录按轮次和说话人切。我拿同一个 embedding 模型测试三种切分策略切分方式对话类问题召回命中率时间线类问题命中率固定 512 字符42%38%按段落63%52%按语义边界章→段→句81%74%差距不是一点半点。所以第一课是动手写向量化脚本之前先拿你手头语料的 20 个典型问题做切分策略测试哪种命中率最高就用哪种。3.2 教训二Metadata 是让 RAG可调试的关键而不是可有可无的装饰如果没有 metadataRAG 就像一个没法断点调试的黑盒。我在初版踩了盲人摸象的坑后把 metadata 当成了和向量同等重要的资产。具体做法CREATE VIRTUAL TABLE novel_vss USING vss0( chunk_id TEXT, chunk_text TEXT, chapter_no INTEGER, chapter_title TEXT, characters TEXT, start_char INTEGER, end_char INTEGER, embedding float[512] );注意这里向量列放在最后其他字段是原始列。实际用 SQLite 虚拟表时筛选条件写在外层查询向量检索写在内层这样既能利用 vss 索引又不受 metadata 限制。3.3 教训三不要只用最终答案判断 RAG 好坏要拆开看检索环节我一开始只看大模型最终回答得对不对导致出现硬伤一和硬伤二时我一直以为是大模型不行。后来我学会把检索链路单独评测精确率Precision召回的 chunk 里有几个真的是相关证据召回率Recall针对某个问题正确答案覆盖了几个 chunkHit Rate问题能在 Top-K 里找到至少一个相关 chunk 的比例。这三项指标要分开看。往往是召回率不错但精确率惨不忍睹——说明检索捞了一大堆没用的东西生成阶段自然会胡说。把精确率和召回率分开优化比直接调 prompt 更本质。3.4 教训四动态 Top-K 配合相关性阈值比死值可靠十倍如果你也用固定 Top-K我建议改成下面这种模式query_vector get_embedding(question) candidates collection.query(query_vector, k20, filter{chapter_no: chapter_filter}) reranked mmr_rerank(candidates, query_vector, lambda_weight0.7) final_chunks [c for c in reranked if c.score 0.42][:5]这里的 0.42 只是示例阈值你需要基于自己的评测集校准。重点在于先召回 20 条再做冗余惩罚MMR再卡阈值最后保留 5 条走生成。整个过程比直接取 Top-K5 稳定得多尤其小说这种词汇分布不均匀的语料。3.5 教训五生成阶段要省着用上下文不能指望模型啥都看完很多人把长文档 RAG 做成把能搜到的全塞给模型这在测试集上偶尔表现好但在真实场景中会迅速暴露上下文窗口的限制。更合理的策略是检索阶段尽量精炼只带 2-3 个高度相关内容。生成阶段用提示词明确严格基于上下文中的文本回答。如果模型支持工具调用甚至可以先让模型决定要不要追加检索这就是轻量版 agentic RAG。我这轮项目还没把 agentic 全面落地但已经验证了先精检索再生成这个方向。下一步我会往这个方向继续叠功能。4. 第二个 RAG 我会怎么调整落地级方案的升级清单复盘完第一个项目其实脑子里已经在重做一版了。如果你也要从零做 RAG这里有一份我基于踩坑经历升级后的清单应该能帮你少走不少弯路。4.1 存储与索引层从单库文件升级为库 索引分离结构第一版用 SQLite 单文件其实没问题但当我开始加入 metadata 筛选和高频查询时文件锁和 I/O 冲突变多了。第二个 RAG 我会采用SQLite 作为元数据核心库向量索引单独建在 sqlite-vec 的独立虚拟表或者干脆在需要并发时换成 pgvector。这里的重点是一个经验卡点元数据和向量分开存查询时再 join。这样你可以用常规 SQL 做复杂过滤比如只看第 8 章 人物 A 时间在 3 万字附近而向量库只负责相似度计算两者解耦后调试方便多了。4.2 数据接入层加工管线做成可重跑的 ETL 流程第一个项目我直接在脚本里边读小说边切边向量化改一次策略就得重新跑全量。第二个项目我会建议用完整的 ETL 管线——抽取、清洗、分块、标注 metadata、向量化、入库、校验——每个阶段都有中间产物可以单独重跑某一步。另外补充一个很多人忽略的点预处理阶段要清理特殊字符。小说文本里经常有 em 破折号、全角引号、乱码空格这些字符不做消毒会让分块边界和向量质量出现不可控的问题。dbx 这类图形工具能帮你快速查看入库前后的文本差异排查脏数据很方便。4.3 检索策略层从单路向量检索升级为多路召回 融合重排实际场景里纯向量检索不适合所有问题。比如用户问第 8 章标题是什么这本质上是一个精确匹配问题向量检索可能答错再比如哪一章出现了神秘酒馆可能需要全文关键词召回。我的第二个 RAG 会用一个混合检索方案关键词路径BM25解决专名词、数字、标题类问题。向量路径解决语义相似、模糊表达问题。融合层对两路结果做 RRF倒数排名融合或加权归一化再进重排。这套方案在小说的章节标题、人名匹配类问题上特别有效也贴合很多做知识库的同学会碰到的半结构化混合检索需求。4.4 评测与调优层建立你自己的金标准评估集最后也是最重要的——如果没有一套固定评测集你永远不知道一次切分策略的改动是变好了还是变坏了。我会为每个 RAG 项目专门准备 30~50 个问题且覆盖这些类型事实定位类主角的母亲叫什么关系梳理类A 和 B 是什么关系时间线类主角离家后经历了哪些阶段观点/情绪类主角对复仇的态度有没有变化每次改动检索、切分、embedding 后都跑一遍记录 Hit Rate 和前几个回答的主观质量分。没有评测集的 RAG 就是盲飞这也是我做完第一个项目最深的感受。一点实操心得收尾项目做到最后我最大的体会是RAG 与其说是给大模型加外挂数据库不如说是一场对文本工程能力的综合考核。从分块到 metadata从检索到重排每一步都在决定最终回答的可信度。第一个版本能跑通值得高兴但五个硬伤远比那行RAG 已上线的提示更值钱。最后分享一个我测试时特别实用的小技巧先不要看大模型的最终回答直接把检索出来的 top-3 chunk 打出来给你自己看。如果这些 chunk 你自己读起来都觉得答非所问那就别指望大模型能救活。这个习惯帮我过滤掉至少一半的假成功测试——因为很多时候大模型很会脑补表面上答得像模像样其实证据根本不对。真正好用的 RAG应该是让你自己先信得过检索结果再谈生成质量。