摘要

以《天龙八部》EPUB拆解RAG全链路：EPubLoader章节加载、RecursiveCharacterTextSplitter分块、Milvus流式入库，实现语义问答。

一、一本百万字小说AI如何读懂它？

本案例采用金庸的《天龙八部》EPUB电子书，完整演示工业级RAG管线：

• 文档加载 → 文本分块 → 向量化 → 存储到Milvus → 语义检索 → LLM问答

至于项目依赖，

{ "@langchain/community": "^.",// EPubLoader
"@langchain/textsplitters": "^."。// RecursiveCharacterTextSplitter
"@langchain/openai": "^.",// Embeddings + ChatOpenAI
"@zilliz/milvus2-sdk-node": "^.",// Milvus 客户端
"epub2": "^.",// EPUB 解析底层库
"html-to-text": "^." // HTML → 纯文本转换 }

三个文件对应三个阶段：main.mjsquery.mjsrag.mjs。

常见痛点这方面，

• 内存使用过大整本书一次性加载导致 OOM。
• Embedding API 调用限流批量请求易触发速率限制。
• 分块参数不当导致检索精度下降
• Schema 不通用，难以 多本书
• 查询结果缺少上下文定位信息

二、文档加载：EPubLoader按章节拆解电子书

import { EPubLoader } from '@langchain/community/document_loaders/fs/epub';const loader = new EPubLoader;说起来，const documents = await loader.load;console.log，

splitChapters: true 是关键配置——它让 Loader 按章节拆分，而不是把整本书作为一个大字符串返回。其实，每个章节是一个独立的 Document 对象。 包含 pageContent和 metadata。

使用者痛点提示：如果不开启 splitChapters。后续分块与向量化都会被迫在极大的文本上操作，导致性能骤降。

说到优势概览。

• 从天然结构边界来看，避免跨章拼接错误。不过，
• 逐章粒度可控的观点是。内存使用与 API 调用均可控制。按理说，
• Easier debugging：单章失效时可以快速定位。

三、文本分块：RecursiveCharacterTextSplitter 的切割策略

为什么必须分块？

Embedding 模型对超长文本的语义表达能力下降；其实，检索时返回整章内容导致答案冗长且不精准。方法是将每个章节进一步拆成若干小片段。