做 RAG 时最先该跑通的不是大模型。而是“资料找回”

使用者痛点： 大多数开发者在实现RAG时过于关注大模型的调优，而忽视了最基础的检索功能。这导致程序回答不准确、难以维护，最终体验糟糕。

摘要： 用《天龙八部》EPUB 做知识库时真正容易出错的不是 Prompt，而是文本切分、向量入库和 Milvus SDK 的响应字段。老实说，这篇文章基于一个 Node.js + LangChain + Milvus/Zilliz 练习项目。拆解从 EPUB 到检索提高生成的最小链路，并给出一份排错清单。运行未验证。

使用者痛点： 开发者常常发现大模型直接回答问题比使用RAG更快捷，但这样无法保证答案来自指定知识库。如何确保回答来源可信，

当你问“鸠摩智会什么武功”时大模型当然可能直接回答。但如果目标是做一个基于指定小说内容的问答程序，不能只依赖模型参数里的知识。

使用者痛点： 初学者往往不知道从何入手RAG开发，尤其对资源有限的人如何高效建立可靠的检索程序？

更可靠的流程是：先从书里找相关段落，再让模型基于段落回答。这是 RAG 的主要，对初学者来说先把“找对资料”这件事跑通比不断修改 Prompt 更关键

这个项目如何把一本 EPUB 变成可问答知识库

使用者痛点：开发者需要明确每个组件的具体职责和工作流程才能有效排查问题。

项目分成三个脚本，职责很清晰：

书籍内容 → 文本块 → 向量 → Milvus问题 → 问题向量 → 相似文本块 → Prompt → 回答
这里有两个模型角色：
Embedding 模型：把文本和问题都变成向量,用来检索;Chat 模型：读取“问题 + 检索到的文本”,负责生成自然语言回答。一个负责定位,一个负责表达。

为什么要特别注意“资料找回”阶段?


典型场景示例这方面，当遇到如下情况时:

再看原因分析。


数据未正确入库: flush未调用或维度不匹配导致写入失败

查询参数错误: vector格式不对或limit设置为0

SDK使用错误: results字段名写错/嵌套层级理解错误

至于**方法，**
javascript
console.log // 输出完整响应结构再处理!



从错误恢复机制来看，


javascript
try{
await insertDocs
} catch{
logError
await retryInsert // 自动重试策略...
}


最终建议: 在投产前务必做压力测试 - 用benchmark-tools评估极限性能!