RAG 实战：用 LangChain 从零建立智能知识库问答程序

一、为什么需要 RAG？

大模型能回答什么主要取决于训练数据。如果问题涉及公司内部文档、项目规范、产品最新说明或实时业务数据，模型可能根本没有这些知识。

使用者痛点：

• 内部信息分散在 PDF、Excel、Confluence 等多种格式中。
• 模型经常“自信”生成错误答案，导致业务风险。
• 缺乏可追溯的答案来源，难以满足合规要求。按理说，

更麻烦的是模型不大概率会直接说“不知道”。而可能生成一段听起来合理、没有依据的内容，这就是大模型幻觉。

光光和东东是怎么成为朋友的？

如果模型没有读过这段故事，它可能会根据片段回答。

使用者问题 → 检索知识库中的相关片段 → 把片段加入 Prompt → 大模型基于资料生成回答

RAG 的全称是 Retrieval-Augmented Generation

• Retrieval: 检索；
• Augmented: 提高上下文；其实，
• Generation: 生成答案。

二、RAG 和微调有什么区别？

微调适合改变模型的任务能力、输出格式或表达风格；按理说，RAG 更适合给模型补充经常变化的外部知识。

{/* 配图：请插入 rag-vs-finetune-cartoon.svg，放在本节表格之后 */}

三、RAG 的主要链路

RAG 可以拆成入库和查询两个阶段。

入库阶段

原始文档 → 文档切分 → Embedding 向量化 → 保存向量、原文和元数据

CUT 太大 => 无关内容过多；CUT 太小 => 语义被破坏。话说回来，切分是 RAG 效果的第一步先关键。

查询阶段

使用者问题 → 问题向量化 → 与文档向量计算相似度
→ 返回 Top‑K 片段 → 拼接成上下文 → 大模型生成答案

四、向量搜索是怎么工作的？

关键词搜索依赖字面匹配，但表达方式不同也能导致检索失败。怎么说呢，Embedding 把文本转成数值向量。相近语义往往在向量空间中更靠近。

“东东喜欢画画” ->

• 入库时把每个文档片段转成向量；
• 查询时把使用者问题转成向量。
  • 从余弦相似度来看，cos=A⋅B/ 仅示例公式。不同实现可能略有差异].
    • 维度越高不一定更好，需要结合 Embedding 模型质量与检索策略来决定。

      { /* 配图：请插入 rag-vector-search-cartoon.svg，放在本节公式之后 */ }
      

五、项目结构和环境配置

rag-demo/ ├── .env ├── src/ │ ├── index.mjs │ └── custom-embeddings.mjs └── readme.md

.env 示例：

bash MODEL_NAME=qwen-plus EMBEDDINGS_MODEL_NAME=text-embedding-v3 OPENAI_API_KEY=your-api-key OPENAI_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1

提示不要把真实 API Key 提交到 Git 仓库；生产环境请通过后端安全存储。

六、逐段解析主要代码

导入依赖