用 Vue3 + Node.js + RAG 构建 Al 讲义问答系统(接入豆包大模型)_js 接入豆包怎么处理返回内容当中的样式-CSDN博客

本文链接：https://blog.csdn.net/python12345678_/article/details/148254767

随着大语言模型（LLM）的迅猛发展，将其应用于教育领域的讲义问答成为可能。然而，传统大模型在处理超出训练数据范围的专业问题时，往往会出现 “幻觉”（即捏造不正确的内容），降低回答的可信度。为了解决这一问题，业界提出了 检索增强生成（RAG，Retrieval-Augmented Generation） 技术。简单来说，RAG 就像让模型在开卷考试 —— 在回答问题前，先从外部知识库（如讲义文档）中检索相关资料提供给模型参考，从而提高答案的准确性并减少不可靠的臆测）。

在这里插入图片描述

本教程将手把手教你使用 Vue3.5 + Node.js + RAG 架构构建一个 AI 讲义问答系统原型，并接入字节跳动的 豆包大语言模型 API 实现问答。在本文中，你将了解 RAG 的原理和优势，对比 Fine-tuning（微调）方法的异同；掌握系统的整体架构设计与技术栈选型；深入剖析文档分段、向量嵌入、相似检索、Prompt 构造、以及大模型调用等核心模块的实现；最后，我们还将提供豆包 API 接入的实战代码示例、前后端组件划分、项目部署方案，以及实际效果截图与应用场景拓展建议。希望通过本文的讲解，读者可以自行搭建一个原型系统，并将其拓展应用到自己的教学或知识问答场景中。

RAG 技术简介：让大模型学会 “开卷考试”

在传统闭卷模式下，大模型只能依赖训练时 “记住” 的知识回答问题。当问题涉及模型训练数据之外的最新资讯或特定领域知识时，模型要么拒绝回答要么张冠李戴，难以令人满意。Retrieval-Augmented Generation（检索增强生成，简称 RAG）提供了一种折中的解决方案：不给模型继续 “补课” 微调，而是在回答时临时为它提供一份外部资料。这样模型就像开卷考试一样，可以一边参考资料一边作答，从而显著减少了事实性错误的发生。

RAG 的核心原理可以分为三个步骤：

\1. 索引（Indexing） ：将原始文档（如课程讲义）进行分段处理，每段形成独立的内容块（chunk），并使用嵌入模型将每个内容块编码为向量表示，存储到向量数据库中备用。

\2. 检索（Retrieval） ：当用户提出问题时，先将问题转换为向量，在向量数据库中搜索语义相似的内容块，返回与问题最相关的 Top K 个片段。

\3. 生成（Generation） ：将检索到的内容片段连同原始问题一起，按照预先设计的 Prompt 模板提供给大语言模型，让模型基于这些外部知识生成答案。

通过上述流程，RAG 能让大模型在无需改动内部参数的情况下动态利用外部知识库来回答问题，大大提升专业问答的准确性和时效性。同时，由于不需要对模型进行昂贵的精调训练，RAG 极大降低了定制应用的实现成本。正如 AWS 对该技术的描述：“微调一个基础模型代价高昂，而 RAG 提供了一种更具成本效益的方式将新知识引入模型”。因此，在需要频繁引入新知识（如课程新内容、最新研究）或针对有限领域进行问答时，RAG 往往是比 Fine-tuning 更优的选择。当然，RAG 也有其挑战，例如需要维护额外的知识库和检索模块，但在工程上通常比动辄上百亿参数的模型微调要简单可行得多。

系统架构设计与技术栈选型

本小节我们将介绍本项目的系统架构设计，并解析所用技术栈（Vue3.5 + Node.js + MongoDB + Faiss + 豆包）在其中担任的角色。

图 1：典型 RAG 问答系统的架构示意图，分为 “数据索引”（左侧）和 “检索生成”（右侧）两大阶段数据索引阶段先从各种格式的讲义资料中提取原文，将长文拆分为较小的文档片段，对每个片段计算其 Embedding 向量并存入向量数据库。检索生成阶段中，当用户提出问题时，系统将问题向量化并与向量数据库中的数据进行匹配，召回最相关的内容片段；随后将这些片段注入到 Prompt 中提供给 LLM，最终由大模型生成精准且有依据的答案。

在这里插入图片描述

在本项目中，整体架构遵循上述 RAG 流程，具体技术实现上采用了前后端分离模式：

前端（Vue3.5）

使用 Vue.js 搭建单页应用界面。Vue3 的组合式 API 提高了代码组织和状态管理的灵活性，非常适合构建交互式问答界面。本系统前端主要包含：讲义文档的上传页、问答对话页，以及用于显示检索结果高亮片段的组件等。通过 Vue Router 可以实现上传和问答视图的切换，组件划分上将文件上传、问答对话框、答案展示 / 引用高亮等功能模块化，方便维护和复用。

后端（Node.js）

使用 Node.js 搭配 Express/Koa 等框架构建后端服务。Node 在处理 I/O 密集型任务（如文件上传、调用外部 API）上性能良好，并且可以方便地与前端进行 JSON 接口交互。我们的后端需要负责文档预处理、向量检索和与大模型 API 的交互等核心逻辑。

数据库（MongoDB）

用于存储上传的讲义文档原文、分段后的内容以及元数据等。MongoDB 的文档型存储非常适合保存不定长的文本段落，并能灵活索引。我们也可以将每个文档片段和其对应的向量索引相关联存储，便于检索结果定位原始内容。

向量索引库（Faiss）

Facebook 开源的高效向量相似度检索库 Faiss，用于存储和搜索文本片段的 Embedding 向量。通过 Faiss，我们可以在大量片段中快速找到与用户问题最相似的若干向量，从而定位相关内容片段。Faiss 通常以 Python/C++ 实现，但我们可以通过离线构建索引并加载，或借助 faiss-node 等 Node.js 接口来集成（npmjs.com）。在初始原型中，数据量不大时也可以简单地将向量存入内存数组，用余弦相似度计算进行 TopK 搜索；但如果讲义库规模较大，Faiss 等专业向量库的效率优势就非常明显了。

大语言模型（豆包）

由字节跳动火山引擎提供的 豆包系列大模型 作为回答生成的 AI 引擎。选择豆包的原因有三：

\1. 成本友好：豆包提供对个人开发者友好的 API 服务，支持高达 50 万 tokens 的免费额度试用，成本低廉；

\2. 长上下文支持：豆包模型支持 4k、32k 甚至 128k 长上下文窗口（liduos.com）—— 使用 Doubao-128k 模型可以一次注入非常长的提示和资料，非常适合我们的讲义问答场景；

\3. 接口兼容：豆包 API 与 OpenAI 的接口高度兼容，接入非常方便。后文我们会详细介绍如何获取和调用豆包的 API。

综上，系统架构可以概括为：用户通过前端上传讲义 → 后端对文档进行分段和向量化并存储 → 用户在前端提问 → 后端检索相关片段并构建 Prompt 调用豆包模型 → 将答案和引用依据返回前端展示。下面我们将深入这些核心流程的实现细节。

核心模块详解：从文档到答案的流水线

这一部分我们按实际系统流程，逐步剖析各核心模块的功能与实现方式，包括：文档上传与预处理、内容分段与向量嵌入、相似度检索、提示词（Prompt）构造以及大模型调用生成答案。

1. 文档上传与内容预处理

首先，用户通过前端界面上传讲义文件。目前我们支持常见的文本型讲义格式，例如 PDF、Word 文档或纯文本文件。前端调用后端的上传接口将文件传至服务器后，我们需要进行以下预处理：

• 文本提取：针对 PDF/Word，我们使用相应的解析库提取出纯文本内容。例如在 Python 端可使用 PyMuPDF (fitz) 或 pdfplumber 提取 PDF 文本，在 Node.js 中则有 pdf-parse 等库。统一得到完整的讲义文本字符串。

• 内容分块（Chunking） ：将整篇讲义按段落或页码进行拆分，生成较小的文档片段列表。分块的策略可以根据内容结构调整：通常按自然段落或章节划分，每块控制在几百字以内较佳。这是因为过长的片段在向量表示时会 “稀释” 语义且增加检索噪音。例如我们可以按段落分段，或每隔 N 个句号拆分一次。同时记录每个片段的来源（所在页码或段落位置）以便后续高亮显示。

• Embedding 向量生成：将每个文档片段通过向量嵌入模型编码为向量表示。这里我们可以选择开源的中文文本嵌入模型（如 SentenceTransformer 的多语言模型）或使用第三方 API（如 OpenAI Embedding API，或者火山引擎自身提供的 doubao-embedding 向量模型，。假设我们采用一个预训练模型来获取 768 维的向量表示。对于 Node.js 项目，可以在后端通过 Python 脚本调用 embedding 模型，然后将结果传回；为了简化，也可以调用在线向量服务获取结果。每个片段的 embedding 向量计算完成后，存储到向量索引库中，并在数据库记录该片段的文本、向量及其所属文档等信息。

完成以上步骤后，知识库的准备就绪：我们的 MongoDB 中存放了所有文档片段及其元数据，Faiss 中构建了对应的向量索引。这相当于建立了问答系统的 “外部知识库”。

2. 向量检索与相关片段召回

当用户在前端输入一个问题时，后端将执行 RAG 检索流程来找到相关内容：

• 问题向量化：类似地，我们对用户提问的文本使用相同的嵌入模型编码为向量 q。

• 相似度搜索：将问题向量 q 在之前构建的向量索引（Faiss）中进行相似度查询，寻找与 q 最近邻的 Top K 个文档片段向量。Faiss 提供高效的 search 接口，一行代码即可完成如 index.search(q, k) 获取最相似的 k 个向量及对应的索引。返回的这些片段就是与问题语义上最相关的内容块。我们可以设定 k 比如 3~5，以平衡召回内容的丰富度和干扰。必要时也可以在纯向量相似度的基础上增加简单的交叉检索或过滤，比如同时采用关键词 BM25 检索排序融合，或者按片段所属文档做均衡等，但初版系统可以先直接采用向量相似度排序结果。

• 相关片段集合：根据检索结果的索引，查询 MongoDB 获取对应的片段文本内容。如果存有片段所在的文档标题或其他标识，也一并取出，方便在答案中引用来源。为了直观起见，我们也可以选择仅取 Top1 或 Top3 的片段，将过多片段喂给模型可能增加噪音并占用上下文长度。

通过以上检索步骤，我们拿到了一个与用户问题高度相关的内容片段列表。这些片段就是大模型作答时可参考的 “开卷材料”。接下来需要把材料和问题包装在一起，构造提示给大模型。

3. Prompt 模板构造与大模型调用

Prompt（提示词） 是引导大模型生成所需答案的指令文本。在 RAG 场景下，Prompt 通常包括：对模型的角色或任务指示、检索到的外部内容片段、用户的问题，以及希望模型遵循的回答格式等。精心设计 Prompt 能有效提升答案的相关性和可靠性（help.aliyun.com）。以下是一个简化的 Prompt 模板示例：

bash体验AI代码助手代码解读复制代码# 系统角色定义

系统：你是一个可靠的教学助手，只根据提供的讲义内容回答问题。如无相关信息，请回答“未找到相关内容”。
# 讲义片段列表，可根据检索结果动态填充

讲义片段1：

「<片段1文本>」

讲义片段2：

「<片段2文本>」

...

# 用户问题

问题：<用户的问题>

# 指令模型作答

请根据上述讲义内容，用简洁中文回答：

在上面的模板中，我们首先以系统角色告诉模型它的身份和规则（例如不得凭空发挥，只能根据提供内容回答）；然后依次列出检索到的讲义片段，每段可以用引用符号或其他方式标明是资料内容；最后呈现用户的问题，并请模型依据资料作答。如果检索片段很多，可以在 Prompt 中注明 “以下摘录自讲义的相关内容”，并在每段结尾标注来源页码等信息，增加权威性。

构造好 Prompt 字符串后，我们就可以调用 豆包大模型 API 来生成回答了。豆包的大模型提供了 OpenAI ChatGPT 类似的对话接口，支持 Chat Completions API 格式, 。我们可以选择直接使用火山引擎提供的 SDK，或利用 OpenAI 官方 SDK 设置自定义 base_url 实现。下面给出使用 OpenAI 的 Node.js SDK 调用豆包模型的示例代码：

javascript体验AI代码助手代码解读复制代码// 安装 openai 库: npm install openai
const { Configuration, OpenAIApi } = require("openai");

// 用火山引擎的 API Key 和接口地址配置 OpenAI SDK
const configuration = new Configuration({
  apiKey: process.env.ARK_API_KEY,  // 火山方舟平台获取的 API 密钥
  basePath: "https://ark.cn-beijing.volces.com/api/v3",  // 豆包服务的地址
});
const openai = new OpenAIApi(configuration);

// 构造请求体
const endpointId = "<你的豆包 Endpoint ID>";  // 豆包推理接入点ID
const messages = [
  { role: "system", content: "你是讲义问答助手，只根据提供的资料回答问题。" },
  // 将检索到的片段作为一个系统消息或用户消息插入
  { role: "system", content: "讲义参考资料：\n" + combinedChunksText },
  { role: "user", content: userQuestion }
];

// 调用豆包模型生成答案
openai.createChatCompletion({
    model: endpointId,
    messages: messages,
    temperature: 0.7
}).then(res => {
    const answer = res.data.choices[0].message.content;
    console.log("AI回答:", answer);
}).catch(err => {
    console.error("调用豆包API出错:", err);
});

如上，我们将豆包的推理接入点 Endpoint ID 当作模型名，API Key 放入 Authorization 请求头，调用的域名为火山方舟的 ark 服务地址。豆包的 Chat API 与 OpenAI 的接口协议兼容，这意味着只需替换接口地址和模型 ID，就能用 OpenAI SDK 调用豆包模型。在调用前，需要先登录火山引擎账户获取 API Key，并创建对应模型的推理接入点（例如选择 doubao-pro-32k 或 doubao-lite-32k），获取到 Endpoint ID。豆包提供专业版和轻量版模型以及不同上下文长度的配置，开发者可根据精度和成本需求选择。

稳定性说明：实际调用豆包 API 时，一般需要注意：适当控制请求频率，避免触发限流；对长篇幅提问，合理利用大模型的长上下文优势但也注意超长输入可能增加响应延迟；遇到网络波动或返回超时，做好简单的重试机制。根据火山引擎的服务协议，官方对大模型服务的可用性尽最大努力保证但不做绝对承诺—— 这和调用任何云端大模型服务类似。在我们实际测试中，豆包 API 调用比较稳定，高并发情况下也能保持较低的故障率和延迟。另外一个实践经验是充分利用免费额度做调优：火山方舟目前给每个模型赠送 50 万 tokens 试用，足够在上线前进行大量测试，从而优化 Prompt 模板和检索参数，使系统达到最佳效果。

当豆包模型返回答案后，后端会对原始回复进行必要的后处理，例如去除不需要的客套话，或依据模型返回的 finish_reason 字段判断是否需再次补全等。最终的答案文本将和引用的文档片段一起返回给前端。

前端页面结构与高亮展示

在前端，我们使用 Vue3 构建了一个简洁直观的单页应用，使用户可以方便地完成文件上传和问答交互。这里介绍页面路由设计和组件划分，以及答案高亮显示的实现思路。

页面路由设计

• /upload 文档上传页：提供文件选择或拖拽上传功能。用户可以在此页面添加新的讲义文档。上传后，前端调用后端接口完成文档处理，并导航至问答页。

• /chat 问答对话页：主界面包含一个提问输入框、发送按钮，以及一个对话记录区域来显示历史提问和 AI 答案。在对话区的一侧或下方，还可以有一个引用片段展示面板。

为了提升用户体验，我们可以在问答页显示当前知识库中文档列表，让用户选择想提问的范围（例如只问某一篇讲义）。不过在本原型中，我们默认对所有上传讲义进行检索。

组件划分*

• 封装文件上传的输入框和拖放区域，内部使用 Input [type=file] 触发上传事件。通过 $emit 通知父组件上传的文件列表。

• 提问输入框组件，绑定用户输入的提问内容。按下回车或点击发送按钮时，通过事件将提问提交给父级处理。

• 对话消息列表组件，用于显示提问和回答的记录。每个消息可以用子组件表示，AI 的回答消息中包含富文本内容（可能带有高亮）。

• 高亮引用片段查看器。当用户收到答案后，如果点击查看来源按钮，可以在该组件中显示相关讲义段落内容并高亮出关键句。我们可以使用第三方 PDF 渲染组件（如 PDF.js）在浏览器中加载 PDF 页面，并利用检索返回的页码定位并以黄色背景标出对应句子。

前端与后端通过 Axios 或 Fetch 调用 REST API 接口。例如：

• POST /api/upload：上传文档接口，携带文件内容。前端拿到响应后弹出成功提示。

• POST /api/ask：提交问答接口，请求体包含用户问题（和可选的限定文档 ID）。前端收到响应的答案后，将其追加到列表。同时，如果响应中带有引用的片段或页码信息，则触发展示。

高亮显示实现*

后端在返回答案时，可以附带检索到的片段文本或者其在原文中的定位。例如，返回片段文本加上所在页码。前端收到后，有两种处理方式：

\1. 直接展示片段文本高亮：将片段文本嵌入到答案的显示中，使用标签包裹其中关键的句子。这种方式简单直接，但无法看到全文上下文。

\2. PDF 页高亮：利用 PDF.js 加载原文档的对应页，将检索到的句子通过搜索定位并调用 PDF.js 提供的高亮绘制接口。我们的项目中可以实现一个简单版本：打开 PDF 到指定页，然后用 CSS 覆盖层模拟突出显示关键词。

作为示例，这里展示第一种方式的实现片段。在后端返回的数据中，假定有字段 references 列表，包含每个参考片段的文本和来源：

xml体验AI代码助手代码解读复制代码<template>
  <div class="answer">
    <p>{{ answerText }}</p>
    <div v-if="references.length" class="references">
      <h4>参考内容：</h4>
      <ul>
        <li v-for="(ref, index) in references" :key="index">
          <!-- 将参考片段中的匹配问句关键词部分包裹 mark 实现高亮 -->
          <span v-html="highlightKeywords(ref.text, question)"></span>
          <em>（摘自：{{ ref.source }}）</em>
        </li>
      </ul>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue';
const props = defineProps({ answerText: String, references: Array, question: String });

// 一个简单的关键词高亮方法：将问句中的每个词在片段文本中高亮
const highlightKeywords = (text, question) => {
  let result = text;
  question.split(/[\s,，。？?.]/).forEach(key => {
    if(key) {
      const regex = new RegExp(key, 'gi');
      result = result.replace(regex, `<mark>${key}</mark>`);
    }
  });
  return result;
}
</script>

以上代码中，我们将答案文本和参考片段渲染出来，并对每个片段调用一个简单的关键词高亮函数。它把用户问题中的每个关键词在片段中用标签标记，从而在页面上以底色突出显示。这种方式能让读者快速定位答案所依据的证据出处。如需更精细的高亮（比如整句高亮），可以考虑让后端直接返回需要高亮的文本段落，在前端直接包裹渲染。

经过上述步骤，一个完整的提问流程就走通了：用户输入问题 → 前端发送请求 → 后端检索 + 调用模型得到答案和引用 → 前端显示答案并标注参考片段。下面我们看看实际运行效果如何。

项目部署与运行指南

完成开发后，我们可以将本项目部署在本地或云端服务器上，以供实际使用。

本地部署

\1. 环境准备：确保安装 Node.js（建议 >=16.x）和 MongoDB 数据库。以及准备好 Python 环境（如果需要用于计算 embedding 或调用 Faiss）。

\2. 安装依赖：在项目根目录运行 npm install 安装前后端依赖模块（包括 openai SDK、Express/Koa、pdf 解析库等）。

\3. 配置参数：将火山引擎的 API Key 和豆包模型 Endpoint ID 配置为环境变量，例如在项目根目录新建 .env 文件：

ARK_API_KEY=你的火山方舟API密钥 ARK_ENDPOINT_ID=你的豆包EndpointID MONGODB_URI=mongodb://localhost:27017/rag_qa

同时，如果使用本地 Python 计算 embedding，确保相关模型文件路径或 API 配置正确。

\1. 启动后端服务：运行 node app.js（或 npm run start），启动 Node.js 后端。应监听预定端口（如 3000）等待请求。

\2. 启动前端：在前端目录运行 npm run dev，然后在浏览器打开 http://localhost:5173（假设使用 Vite 开发服务器）查看应用。上传讲义后即可开始提问测试。

云端部署*

• 可以选择将前后端封装为 Docker 容器部署。编写 Dockerfile 将 Node.js 后端及所需 Python 环境打包，然后使用 docker-compose 将 MongoDB 和后端服务一同部署。前端构建出的静态文件则由 Nginx 等静态服务器托管，或直接部署到 Vercel、Netlify 等前端平台。

• 确保云服务器能够访问火山引擎豆包 API 的域名（需公网环境）。如果担心网络延迟，可以选择部署在国内云厂商，并且火山引擎目前只有北京区域，可考虑服务器选在华北区。

• 注意将敏感的 API Key 配置在服务器的环境变量中，不要直写在代码里。启用 HTTPS 来保证前后端通信安全。

• 如果用户规模扩大，向量检索部分可以升级为独立的向量数据库服务（如 Milvus、Elasticsearch/OpenSearch Vector）以获得更好的扩展性和管理界面。豆包大模型也可以考虑通过火山引擎提供的 OneAPI 网关进行多模型管理切换。

总之，本项目在个人电脑或小型云主机上即可跑通。如果需要对接微信小程序、网页插件等，也可以基于已有的后端服务进一步封装接口。

总结

在本教程中，我们从零开始构建了一个 Vue3+Node.js 的 AI 讲义问答系统，利用 RAG 架构让大模型学会参考讲义内容来回答问题。我们介绍了 RAG 的背景原理，与 Fine-tuning 的对比优势；详细阐述了系统架构和技术选型，并分模块实现了文档处理、嵌入与检索、Prompt 设计、大模型调用等关键步骤；通过接入豆包大模型 API，我们成功让系统能够回答讲义中的问题并高亮标注出处，提高了答案的可信度和可解释性。

对开发者而言，这样的项目具有很强的工程落地性：你可以很容易地替换知识库内容来定制自己的问答助手，或扩展前端界面提供更友好的交互。在实现过程中，也能加深对 RAG 技术链路的理解，为日后构建更多融合大模型的应用打下基础。

希望这篇文章对你有所启发和帮助。如果你感兴趣，不妨动手尝试搭建一个属于你自己的 RAG 问答系统！在实践中不断调优 Prompt 和检索策略，你会体会到让 AI 接入外部知识的奇妙之处。