RAG 实战：3 步将整本《天龙八部》存入向量数据库（一）
——从文本预处理到高维索引，解锁大模型长文本记忆新范式
（记者/资讯编辑）随着大语言模型（LLM）应用边界的不断拓展，检索增强生成（Retrieval-Augmented Generation, RAG） 已成为解决模型“幻觉”与长时记忆缺失的核心技术路径。然而，当语料库的体量从几十页论文跃升至一整部百万字的文学巨著时，RAG 系统面临的不再是简单的 API 调用，而是工程化、策略化的严峻考验。
近日，一篇题为《RAG 实战：3 步将整本《天龙八部》存入向量数据库（一）》的技术文章在开发者社区引发热议。该文摒弃了百度百科式的宽泛理论，直接以实体书为“试验场”，展示了如何将金庸先生笔下的北宋武林世界，转化为机器可读、可检索的向量空间。本文记者特此梳理该实战路径，解析这“3 步走”背后的技术逻辑。
第一步：文本清洗与“父子分块”策略——对抗语义割裂
在多数入门教程中，开发者习惯将按固定字符长度（如 512 tokens）硬切文本。但对于《天龙八部》这种情节交织、人物关系复杂的长篇小说，机械切分会导致段落语义严重割裂——例如，将“乔峰”的降龙十八掌与前文的契丹人身份疑云切断。
该实战方案首先展示了高鲁棒性的文本预处理。基于 tiktoken 或 jieba 分词后的字符流，作者采用了 “父子分块”（Parent-Child Chunking） 策略：以章节为“父级”单位，保留宏观叙事逻辑；在英文语境下通常以段落为“子级”单位，但针对中文古文白夹杂的特点，子块边界被设定为句读符号（句号、问号、感叹号）。这一操作的关键意义在于：存入向量库的“子块”足够精准，便于检索定位；返回给大模型的“父块”则保留上下文，防止信息碎片化。
第二步：嵌入模型选型与异构数据降维
将文本转化为向量是 RAG 的核心。由于《天龙八部》中大量存在人物昵称（如“北乔峰南慕容”）、金庸特有武功招式等稀缺实体，直接使用通用 Embedding API（如 text-embedding-ada-002）虽简便，但会产生语义漂移。
文中提出了实战性的双重降维方案。首先，在预处理阶段，针对文本中的生僻词汇构建了一个小型自定义词典，确保分词器不会将“凌波微步”切断；其次，在向量化阶段，对比了 bge-large-zh 与 m3e-base 等中文优化模型的召回效果。作者强调，在“存入前”而非“检索时”进行数据增强（如为每个段落添加角色-事件摘要元数据）是避免高维向量空间混乱的关键一招。
第三步：向量数据库选型与“标量+向量”混合索引
文末重点落在于工程落地的最后一环——写入策略。面对全书约 120 万字的数据量，作者对比了 Milvus 与 Chroma 的实际表现。文章指出，单纯依赖余弦相似度检索容易导致“查得准但排不全”。
该实战引入了倒排索引与向量索引的混合搜索（Hybrid Search）。具体而言，在将文本向量写入数据库时，同步保留“出场人物”、“所在章节”、“文本情感极性”等结构化标签（标量字段）。当用户提问“段誉在哪里学得六脉神剑”时，数据库首先通过向量召回相近表述，再利用 SQL 标量过滤限定章节范围，极大提升了精确度。这一步骤在物理上完成了从“存储文本”到“存储知识关联”的跃迁。
行业观察：从“炫技”到“基建”
截至发稿前，该系列文章已获得数千次收藏。技术评论人士指出，虽然“3 步”看似简单，但其核心价值在于揭示了 RAG 在真实复杂语料下的容错机制。当前的 AI 应用开发已进入深水区，能否高效、低成本地将垂直领域知识“灌入”数据库，比调整 Prompt 更能决定应用上限。
针对《天龙八部》的实战仅仅是序章，后续是否会开放索引构建源码，以及如何解决百万级向量下的极速检索延迟，将是该系列文章下一期的最大看点。预计将引发更多开发者对 RAG 长文本工程化的深度探讨。