不过，

先从把我整懵的那行输出说起

事情是这样的，我准备了 段小故事 当知识库。问了一句「东东和光光是怎么成为朋友的」，按道理应该返回最相关的 条文档。结果控制台打出来这么个东西：

说到我第一反应是。不对啊，第三条原始分，第一条，按理说分越高越相似，怎么第三条排在最前面？

我还特意去核对了内容。第三章讲足球比赛、第六章讲成为好朋友，明显和问题更贴合，原始分反而更低。当时我脑子里闪过好几种可能：是不是我文档顺序放错了？是不是 k 参数写反了，是不是向量库存的时候顺序乱了？

折腾了快二十分钟我才拍了下大腿 —— 这返回的根本不是相似度，是向量距离。距离越小，说明两个向量在空间里越近，语义才越像。

记死这个LangChain 里 similaritySearchWithScore 返回的原始分默认是余弦距离越小越相似。想转成我们直觉里的「相似度」。用 1 - 距离（或 -距离) 就行，数值越大越相关。

就这么个小细节卡了我半小时。说出来挺可笑，但真上手的时候，没人提醒还真容易绕进去。

先掰扯清楚的观点是。RAG 到底在干一件什么事

RAG 全称 Retrieval‑Augmented Generation可以把它当成开卷考试

• 大模型本身是个背书很强的学生，但只记得训练数据里的东西，新故事新文档它不知道。
• 不开卷。它会瞎编，也就是简单讲的幻觉。
• RAG 就是考试前先把参考资料都给你。你答题时先从资料里翻出和问题最相关的几段，再照着这些材料组织语言回答。

整个流程拆成三步：

1. 预处理: 把资料拆成段落。每段转成向量，存到向量库。
2. 检索: 把使用者提问也转成向量，在库里找最近的几段文本。
3. 提高生成: 把找到的段落和问题拼在一起喂给大模型，让它只根据这些材料回答。

主要就是「先搜再答」，用来解决大模型不知道新知识、容易胡说八道的问题。

从第一步先来看，把你的知识库拆成「文档」

L​angChain 里最基础的单位叫 Document. 它不是整篇文章，而是你向量化后最小的单元.

new Document({
pageContent: `东东是光光最好的朋友。他是一个安静而聪明的男孩...`,metadata: {
chapter: 1,character: "东东",type: "角色介绍",mood: "温馨"
},})

Pain Point #1：误以为 metadata 会参与向量化！

• pageContent: 唯一会被 embedding 模型转成向量、参与语义匹配的字段。
• metadata: 附属信息。仅用于过滤、溯源、展示，不参与计算。

# 示例 - 按章节过滤只搜索第 3‑5 章 - 返回结果时告诉使用者答案来自第几章、什么类型等。

至于接下来。塞进内存向量库 & 版本坑提醒

L​angChain 提供内存版向量库 MemoryVectorStore. 注意导入方法已迁移至 @langchain/classic,老教程会报错找不到模块。

import { MemoryVectorStore } from '@langchain/classic/vectorstores/memory';说起来，import { OpenAIEmbeddings } from '@langchain/openai';// 初始化 embedding
const embeddings = new OpenAIEmbeddings({
至于apiKey，process.env.DASHSCOPE_API_KEY。model: process.env.DASHSCOPE_EMBEDDINGS_MODEL,configuration: { baseURL: process.env.DASHSCOPE_API_BASE_URL }
});// 一行代码搞定：把 Document 数组转成向量并存入内存
const vectorStore = await MemoryVectorStore.fromDocuments;console.log，

Pain Point #2：版本/方法频繁变动

• L​angChain 更新快；导入方法、API 名称经常改动。遇到报错先查官方最新文档，不要死抱老教程浪费时间。
• `fromDocuments` 已帮你完成遍历、embedding、存储。一键搞定，无需手动处理向量细节。

检索的两种姿势：retriever vs similaritySearch

Pain Point #3：检索方式混淆 & 分数意义不明

• similaritySearchWithScore: 纯粹向量计算 → 距离/相似度 → 返回 top k + 原始分数。适合快速实验，
• asRetriever → retriever.invoke: 更高层抽象。除了相似度，还能插拔过滤、去重、重排等业务逻辑。生产环境建议使用 retriever，以便后续

// 直接调用向量库
const scoredResults = await vectorStore.similaritySearchWithScore;// 转为标准检索器
const retriever = vectorStore.asRetriever;const docs = await retriever.invoke;

最坑的地方这方面。这个分数到底怎么看

`similaritySearchWithScore` 返回的是**余弦距离**，所以“越小越相似””。如果想要直观上的“相似度”，可以做一次转换：

// 转换示例
scoredResults.forEach => {
const similarity = .toFixed;// 将余弦距离映射到
console.log} | 相似度:${similarity}`);})，

再看最终一步。把搜到的片段塞给大模型，实现完整 RAG

前面完成的是 **R**——Retrieval。 接下来要做 **A** 与 **G**：

// 拼接上下文
const context = docs.map => `
${doc.pageContent}`).join;const prompt = `
你是一个讲友情故事的老师。基于以下故事片段回答问题，用温暖生动的语言。如果故事中没有提到，就说"这个故事里还没有提到这个细节"。怎么说呢，再看故事片段，${context}
问题的观点是。${question}
老师的回答这方面，`;// 调用大模型生成答案
const response = await model.invoke;console.log，

Pain Point #4：忘记给模型“边界”

• AUGMENTED GENERATION 的主要在于让模型只能依据提供的材料作答，从而显著降低幻觉风险。

贴一份能直接跑的完整代码

# 安装依赖

npm install @langchain/openai @langchain/classic @langchain/core dotenv

# 环境变量

DASHSCOPE_API_KEY=你的api_key
DASHSCOPE_API_MODEL=qwen-plus
DASHSCOPE_EMBEDDINGS_MODEL=text-embedding-v2
DASHSCOPE_API_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1

# 完整可运行脚本

import 'dotenv/config';不过，import { ChatOpenAI。OpenAIEmbeddings } from '@langchain/openai';import { MemoryVectorStore } from '@langchain/classic/vectorstores/memory';import { Document } from '@langchain/core/documents';// ---------- 初始化模型 ----------
const model = new ChatOpenAI({
temperature: 0,model: process.env.DASHSCOPE_API_MODEL。apiKey: process.env.DASHSCOPE_API_KEY,configuration: { baseURL: process.env.DASHSCOPE_API_BASE_URL },});const embeddings = new OpenAIEmbeddings({
至于apiKey，process.env.DASHSCOPE_API_KEY。model: process.env.DASHSCOPE_EMBEDDINGS_MODEL,configuration: { baseURL: process.env.DASHSCOPE_API_BASE_URL },});// ---------- 构造知识库 ----------
const documents =;// ---------- 向量化并存入内存 ----------
const vectorStore = await MemoryVectorStore.fromDocuments;console.log，// ---------- 检索 ----------
const retriever = vectorStore.asRetriever;const question = "东董和 光古 是怎么成为朋友 的";console.log，// 使用 Retriever 获得文本片段
const docs = await retriever.invoke;// 同时获取原始距离分数用于对比展示
const scoredResults = await vectorStore.similaritySearchWithScore;// 展示每条检索结果及其转换后的相似度
console.log;docs.forEach => {
const scoreTuple = scoredResults.find => d.pageContent === doc.pageContent);const distance = scoreTuple?scoreTuple : null;const similarity = distance!== null，.toFixed : 'N/A';console.log，console.log: ${similarity} | 原始距离:${distance?说起来，.toFixed?，'N/A'}`);console.log}...`);console.log，});// ---------- 提高生成 ----------
const context = docs.map=>`
${d.pageContent}`).join;const prompt = `
你是一位擅长讲友情故事的老师。请基于以下片段，用温暖生动的话回答问题。如果片段中没有涉及，请回复"这个故事里还没有提到这个细节"。至于故事片段，${context}
问题这方面。${question}
说到老师请作答，`;const answer = await model.invoke;console.log，

*运行提示*: 文件须以 .mjs

跑通之后我踩过的三个坑列给你

1. Pain Point #1 – 分数误解：" 别默认分数越高代表相似度高；先确认返回的是距离还是相似度，再根据实际情况做转换。" 不同库实现不同，一定要手动测一下已知相关文本再决定阈值。"
2. Pain Point #2 – Metadata 并非语义输入：" 把关键词、摘要塞进 metadata 完全不起作用；所有需要被检索匹配的信息必须写进 pageContent." 元数据只能用于业务层过滤或展示。"
3. Pain Point #3 – “一步到位”陷阱：" 初学者常直接套用 PG 向量插件、文本切块器、重排模型等复杂组件，以致一头雾水。建议先用内存版 + 手写少量文本跑通完整流程。再逐步引入高级组件，这样每一步都清晰可控。"

最终说两句

跑通 demo 前，我对 RAG 的认知停留在概念层面看起来很高深；真正动手写完几十行代码，看着控制台输出检索结果与最终答案时我瞬间豁然开朗——RAG 并没有神秘魔法。它但是三件事：

• a. 把知识拆块并向量化存储；b. 提问时先检索出相关块；c. 用这些块喂给大模型生成答案。

The rest—文本切割器、向量数据库、重排模型—都是围绕这三步调整一下。当你的业务需求更复杂，再去引入对应组件即可。

---