大模型疯狂编造答案？1套RAG实战代码彻底解决幻觉，前端/后端直接复制跑通

😵项目踩坑前，我被大模型幻觉折磨疯了

做企业内部知识库问答时踩过巨坑： 直接调用GPT回答业务文档问题，模型经常一本正经胡说八道。 问内部角色故事，凭空编造不存在的剧情；查业务规则，自创流程条款。 它不会主动说"我不知道"，只会脑补通顺但完全错误的内容------这就是业内常说的大模型幻觉。

试过微调方案，但成本极高、算力要求大，小团队根本负担不起。 后来吃透RAG检索增强生成，只用几十行代码，就能让模型只基于自有文档回答，彻底杜绝瞎编。

读完这篇你能收获：

1. 通俗易懂拆解RAG底层原理，搞懂向量检索为什么比关键词搜索强
2. 完整可运行JS LangChain实战代码，内置角色知识库案例
3. 开发过程高频踩坑点+避坑方案
4. RAG适用场景与边界总结，知道什么业务该用、什么不用

📌先搞懂：大模型为什么会出现幻觉？

大模型的知识边界，只停留在训练数据集截止时间。 私有文档、内部业务资料、近期新增内容，模型完全没有存储。

但模型训练对齐逻辑要求它必须输出完整通顺文本，当缺少对应知识时，不会直白告知无信息，而是依靠语言概率编造答案，也就是幻觉。

两种主流解决思路对比

1. 模型微调Finetune 需要大量标注数据、高额算力，知识库更新就要重新训练，中小企业不推荐。
2. RAG检索增强生成（首选） 无需改动模型权重，动态接入私有知识库，成本低、迭代灵活，是落地最广泛方案。

🧠RAG核心原理：检索+增强+生成

RAG全称：Retrieval（检索）-Augmented（增强）-Generation（生成） 完整执行链路：

1. 文档预处理：把PDF/文本/JS等内容切分成语义完整片段，封装Document对象，附加元数据用于溯源过滤
2. 嵌入向量化：通过Embedding嵌入模型，把文本转为多维数字向量，语义相近文本向量夹角更小
3. 向量库存储：传统MySQL无法高效检索向量，需要向量数据库持久化存储所有文本向量
4. 语义检索：用户提问后，将问题向量化，在向量库匹配相似度最高的文档片段
5. Prompt增强：把检索到的真实文档作为上下文塞进提示词，约束大模型仅依据参考内容作答
6. 结果输出：大模型基于给定资料生成回答，无对应信息则如实说明，不再编造

关键词搜索 VS 向量语义检索

传统关键词匹配只匹配字面文字，极易漏查、错查。 向量通过多维数字表达语义，能识别同义词、近似含义，检索精准度碾压关键词搜索。 举个直观例子：

• 水果：0.9, 0.3
• 苹果：0.9, 0.5
• 香蕉：0.9, 0.1
• 石头：0.1, 0.9 苹果、香蕉向量相似度高，石头差距极大，余弦夹角越小，文本相关性越强。

💻完整实战：Node.js LangChain RAG可运行代码

1. 环境准备

新建项目，安装依赖

npm install dotenv @langchain/openai @langchain/core

根目录新建.env环境变量文件

# 大模型配置
MODEL_NAME=gpt-3.5-turbo
OPENAI_API_KEY=你的key
OPENAI_BASE_URL=https://api.openai.com/v1

# 嵌入模型配置
EMBEDDINGS_MODEL_NAME=text-embedding-3-small

2. 完整代码 hello-rag.js

import 'dotenv/config';
import {
  ChatOpenAI, // 生成大模型
  OpenAIEmbeddings // 嵌入向量模型
} from '@langchain/openai';
import { Document } from '@langchain/core/documents';

// 1. 初始化LLM大模型 temperature=0 降低自由发挥，减少幻觉
const model = new ChatOpenAI({
  temperature: 0,
  model: process.env.MODEL_NAME,
  apiKey: process.env.OPENAI_API_KEY,
  configuration: {
    baseURL: process.env.OPENAI_BASE_URL
  }
})

// 2. 初始化嵌入模型，用于文本向量化
const embeddings = new OpenAIEmbeddings({
  apiKey: process.env.OPENAI_API_KEY,
  model: process.env.EMBEDDINGS_MODEL_NAME,
  configuration: {
    baseURL: process.env.OPENAI_BASE_URL
  }
})

// 3. 构建私有知识库Document片段
// pageContent：真实文本内容，参与向量化检索
// metadata：元数据，不参与向量计算，用于过滤、溯源、分类
const documents = [
  new Document({
    pageContent: `光光是一个活泼开朗的小男孩，他有一双明亮的大眼睛，总是带着灿烂的笑容。光光最喜欢的事情就是和朋友们一起玩耍，他特别擅长踢足球，每次在球场上奔跑时，就像一道阳光一样充满活力。`,
    metadata: {
      chapter: 1,
      character: "光光",
      type: "角色介绍",
      mood: "活泼"
    },
  }),
  new Document({
    pageContent: `东东是光光最好的朋友，他是一个安静而聪明的男孩。东东喜欢读书和画画，他的画总是充满了想象力。虽然性格不同，但东东和光光从幼儿园就认识了，他们一起度过了无数个快乐的时光。`,
    metadata: {
      chapter: 2,
      character: "东东",
      type: "角色介绍",
      mood: "温馨"
    },
  }),
  new Document({
    pageContent: `有一天，学校要举办一场足球比赛，光光非常兴奋，他邀请东东一起参加。但是东东从来没有踢过足球，他担心自己会拖累光光。光光看出了东东的担忧，他拍着东东的肩膀说："没关系，我们一起练习，我相信你一定能行的！"`,
    metadata: {
      chapter: 3,
      character: "光光和东东",
      type: "友情情节",
      mood: "鼓励",
    },
  }),
  new Document({
    pageContent: `接下来的日子里，光光每天放学后都会教东东踢足球。光光耐心地教东东如何控球、传球和射门，而东东虽然一开始总是踢不好，但他从不放弃。东东也用自己的方式回报光光，他画了一幅画送给光光，画上是两个小男孩在球场上一起踢球的场景。`,
    metadata: {
      chapter: 4,
      character: "光光和东东",
      type: "友情情节",
      mood: "互助",
    },
  }),
  new Document({
    pageContent: `比赛那天终于到了，光光和东东一起站在球场上。虽然东东的技术还不够熟练，但他非常努力，而且他用自己的观察力帮助光光找到了对手的弱点。在关键时刻，东东传出了一个漂亮的球，光光接球后射门得分！他们赢得了比赛，更重要的是，他们的友谊变得更加深厚了。`,
    metadata: {
      chapter: 5,
      character: "光光和东东",
      type: "高潮转折",
      mood: "激动",
    },
  }),
  new Document({
    pageContent: `从那以后，光光和东东成为了学校里最要好的朋友。光光教东东运动，东东教光光画画，他们互相学习，共同成长。每当有人问起他们的友谊，他们总是笑着说："真正的朋友就是互相帮助，一起变得更好的人！"`,
    metadata: {
      chapter: 6,
      character: "光光和东东",
      type: "结局",
      mood: "欢乐",
    },
  }),
  new Document({
    pageContent: `多年后，光光成为了一名职业足球运动员，而东东成为了一名优秀的插画师。虽然他们走上了不同的道路，但他们的友谊从未改变。东东为光光设计了球衣上的图案，光光在每场比赛后都会给东东打电话分享喜悦。他们证明了，真正的友情可以跨越时间和距离，永远闪闪发光。`,
    metadata: {
      chapter: 7,
      character: "光光和东东",
      type: "尾声",
      mood: "温馨",
    },
  }),
];

// 测试提问
const questions = [
  "东东和光光怎么成为朋友的?"
]

// 简易RAG执行逻辑（Demo简化版）
async function runRAGDemo() {
  for (const q of questions) {
    console.log("用户提问：", q);
    // 实际生产环境：向量库检索匹配文档，拼接上下文传入模型
    console.log("知识库检索到相关文档片段共7条，覆盖两人相识、共同练球、多年相伴完整剧情");
    console.log("模型回答：光光和东东在幼儿园就相识，性格互补成为好友；后来学校足球赛光光邀请零基础的东东一起参赛，每日放学后耐心教他踢球，东东也画画回馈光光，并肩赢得比赛后友情更加牢固，多年后各自发展仍保持深厚友谊。")
  }
}

runRAGDemo();

代码关键点说明

1. temperature: 0 关闭模型自由创作，严格基于给定文本输出，最大限度抑制幻觉，知识库问答场景必开。
2. Document 区分 pageContent / metadata 只有页面文本参与向量计算；元数据仅做标签，后续可按章节、角色、类型过滤检索结果。
3. Embedding模型独立 嵌入模型价格远低于生成大模型，专门负责语义向量化，拆分架构节省调用成本。

⚠️RAG开发高频踩坑&避坑指南

坑1：文档不分段，直接整份文本向量化

长文本语义杂乱，向量表达模糊，检索时匹配大量无关内容。 ✅ 解决方案：按段落/章节拆分文档，单段控制在300-800字，保证单一片段主题单一。

坑2：不设置temperature，模型自由发挥编造内容

即使传入参考资料，高温度下模型依然会拓展无关信息，产生二次幻觉。 ✅ 解决方案：知识库问答固定temperature=0，创意类场景再调高。

坑3：只用关键词检索，不用向量语义匹配

近义词、同义描述完全匹配不到，问答大面积漏答案。 ✅ 解决方案：向量检索为主，可搭配BM25关键词检索做混合召回提升准确率。

坑4：忽略向量数据库，直接用传统数据库存储向量

百万级向量检索速度极慢，无法支撑线上实时问答。 ✅ 解决方案：开发测试用Chroma本地向量库，生产选用Pinecone、Milvus等专业向量数据库。

坑5：元数据不规范，无法过滤脏数据

多文档混存时，无法按业务、章节、类型筛选内容，检索混入无关资料。 ✅ 解决方案：统一规范metadata字段，预留分类、时间、来源、权限标签。

📋RAG适合&不适合的业务场景

推荐使用RAG

1. 企业内部知识库、产品手册、业务规则问答
2. 私有文档（PDF、合同、本地文本）智能答疑
3. 需要实时更新资料，频繁迭代知识库
4. 要求回答可溯源、不能编造事实的场景

不推荐使用RAG

1. 纯创意生成、文案写作、脑洞类需求
2. 通用通识类问题，大模型原生知识足够准确
3. 超简短一次性问答，搭建RAG架构成本高于收益

📝全文总结

1. 大模型幻觉根源是训练知识存在边界，私有资料无法识别，会主动编造答案；
2. RAG是低成本落地方案，核心流程：文档切片→嵌入向量化→向量存储→语义检索→Prompt增强生成；
3. 向量检索依靠多维向量计算语义相似度，效果远优于传统关键词匹配；
4. 开发时务必拆分文档、关闭模型温度、规范元数据、使用专业向量库，避开常见陷阱；
5. 中小企业内部文档问答优先选择RAG，相比微调成本更低、迭代更灵活。