昇腾部署第 G2 课：RAG 基础——企业为什么要私有知识库，两条主线是什么

系列定位：G1 解决了「模型和数据留在自己手里」，G2 开始解决「模型答不了我公司自己的问题」。官方把这块叫 RAG SDK（属 MindSDK 知识增强），本课讲它的定位、结构与两条主线。

第一段章前定位

这课不教你什么：

不教接口怎么调。具体 API 参数随版本变，本课只讲结构；要写代码请查官方《接口参考》。
不教检索调优。那部分是 G4，本课只把「检索」放在正确的位置上。
不做 RAG 与微调的优劣对比。⚠️ 官方文档没有这个对比 —— 本课第 4.4 节给的是 方法层面的归纳，已明确标注，请勿当成官方口径引用。
不涉及用户与权限。官方明确说 RAG SDK 不管这块，那是 G7。

这课要教你什么：

RAG 的价值不在技术多难，而在它把大模型的三个毛病一次性绕过。 但 RAG 也不是「接个文档库就完事」——官方给的开发流程是两条主线、八个步骤，大部分做砸的 RAG，砸在第二条主线的第 3 步（检索）上。

第二段学习目标

大模型的三个毛病分别是什么？RAG 各自怎么绕过？
RAG 的「两条主线」分别是什么？各自几步？
为什么要两个数据库（关系数据库 + 向量数据库）？它们在存什么、怎么对应？
官方 RAG SDK 负责什么、明确不负责什么？
提升检索质量，官方给了哪三条路？（提示：一条在检索时、一条在检索前、一条在检索后）

第三段全景：RAG 要解决什么

3.1 官方点名的三个毛病

官方《RAG SDK 简介》原文：

随着近些年人工智能技术的飞速发展，大模型展现出强大的能力。然而，在实际应用中，大模型仍面临一些挑战，如准确性不足、知识更新速度慢以及答案透明度欠缺等问题。为了解决这些问题，检索增强生成（Retrieval-Augmented Generation，RAG）技术应运而生。 RAG 通过为大模型接入外部知识库，有效提升了问答系统的准确率，解决了大模型的幻觉和时效性问题。

翻译成一句话：

模型不知道你公司的事，而且它不知道装不知道自己不知道。

官方说的毛病	实际表现	RAG 怎么绕过去
准确性不足（幻觉）	模型一本正经地编	答案从检索到的原文里来，不是从模型记忆里来
知识更新速度慢	训练一次要很久，改不了	知识放在外部库里，改库就等于更新知识
答案透明度欠缺	你不知道它为什么这么说	检索到的 context 就是依据，可以给人看

3.2 官方的定位原话（这句是这课的题眼）

RAG 技术能够以较低成本将基础大模型转换为领域专用大模型，成为提升大模型"最后一公里"落地应用效果的关键技术。

⭐ 「最后一公里」这四个字值得琢磨：模型本身多强是一回事， 能不能答对你们公司的问题是另一回事 —— 中间这段就是 RAG 在填。

3.3 官方给 RAG SDK 的边界（这段话决定了它是不是你要的东西）

官方原文：

RAG SDK 是昇腾面向大语言模型的知识检索增强开发套件，为解决大模型知识更新缓慢以及垂直领域知识回答弱的问题，提供各模块化功能接口（包含向量模型垂域微调数据生成、检索、知识管理等功能）供用户开发上层应用，不包含用户、权限等和业务强相关的功能接口。

它主要给三样能力（官方原文）：

能力	官方说明
快速搭建	提供模块化功能接口，按需调用；通过预置的端到端工作流模板，支持用户通过极少量代码快速拉起问答服务
多模态解析	支持文档、表格、PDF、图片等多种类型文件的解析，为大模型提供多样性语料
高性能推理	提供昇腾亲和模型优化加速，实现更高的吞吐和更短的响应时间

⚠️ 那句「不包含用户、权限等和业务强相关的功能接口」是本课埋下的最重要一颗钉子： 官方只给"知识"这一层，业务那一层（谁能问、能问什么、问过什么）要自己造。 这就是 G7 要讲的内容。

第四段【如果我来做】从接到需求到跑通最小链路

4.0 我会按这个顺序走（顺序错了会白干）

① 先判断这事该不该用 RAG（不急着装东西）
     问客户一句话：【你要的答案，有原文可查吗？】
       有原文 → RAG 对路（把原文找出来给模型看）
       没有（是种习惯/能力/风格）→ 不是 RAG 的问题，别硬上
     ⚠️ 这一步跳过的后果：装完一套 RAG，发现要解决的根本不是"知识不在库里"

② 定"最小验证目标"（一个部门 + 一份文档 + 一个问题）
     不要一上来就"把所有制度文件都灌进去"
     目标 = 让一个人用一份真实文档问出一个只有这份文档能答的问题

③ 选库（先跑通，再谈性能）
     文档片段库：SQLiteDocstore（单机零依赖）
     向量库：MindFAISS（昇腾自研，和卡亲和）
     ⚠️ 别一上来就上 Milvus/OpenGauss —— 那些是并发量和规模上来之后的事

④ 装环境（见 G3 第四段，这里不重复）
     一句话验收：python3 -c "import mxRag; print('RAG SDK import: OK')"

⑤ 跑最小链路（下面 4.0.1 的 20 行代码）
     期望结果：控制台打印出检索到的原文片段

⑥ 验"RAG 真的起作用了"（不是模型本来就知道）
     问一个【只有这份文档能答】的问题
     ⚠️ 问"中国首都是哪"答对了不算 —— 模型本来就会

⑦ 换个人问（验收的灵魂条）
     让同事用他的说法问同一个问题 —— 只有你自己能问出来的效果不算效果

⑧ 到这一步才谈调优（G4 的三个调点）
     查询改写 / 近似检索 / reranker 精排

⭐ 这个顺序里最容易被跳过的是 ① 和 ⑥： - ①：判断没做，装完才发现方向不对； - ⑥：拿"答对了"当验收 —— 而模型本来就知道的答案，答对了证明不了任何事。

4.0.1 最小可跑链路（20 行，先跑通再优化）

这一段是 G3 那个完整示例的"精简版" —— 目标是最快看到"检索真的把原文找出来了"。完整版（含多格式注册、目录上传、删除）在 G3 第五段。

# 最小链路：2 个文档 → 建库 → 提出一个问题 → 看检索返回什么
from mx_rag.embedding.local import TextEmbedding
from mx_rag.knowledge import KnowledgeStore, KnowledgeDB, upload_files
from mx_rag.document import LoaderMng
from mx_rag.storage.document_store import SQLiteDocstore
from mx_rag.storage.vectorstore import MindFAISS
from mx_rag.document.loader import DocxLoader, PdfLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter

# ① 解析器：只登记我们真正要用的两种格式
loader_mng = LoaderMng()
loader_mng.register_loader(DocxLoader, [".docx"])
loader_mng.register_loader(PdfLoader, [".pdf"])
loader_mng.register_splitter(RecursiveCharacterTextSplitter, [".docx", ".pdf"])

# ② embedding：dev = 第几张 NPU 卡
dev = 0
emb = TextEmbedding("/path/to/model", dev_id=dev)

# ③ 两个库（最小组合：SQLite + MindFAISS）
vector_store = MindFAISS(x_dim=1024, devs=[dev], auto_save=True)
chunk_store = SQLiteDocstore(db_path="./sql.db")
knowledge_store = KnowledgeStore(db_path="./sql.db")

# ④ 建一个知识库
knowledge_store.add_knowledge(knowledge_name="test", user_id='Default', role='admin')
knowledge_db = KnowledgeDB(knowledge_store=knowledge_store, chunk_store=chunk_store,
                           vector_store=vector_store,
                           knowledge_name="test", user_id='Default', white_paths=["/home/"])

# ⑤ 灌两份文档
failed = upload_files(knowledge=knowledge_db, files=["/home/data/a.docx", "/home/data/b.pdf"],
                      loader_mng=loader_mng, embed_func=emb.embed_documents, force=True)
print("上传失败的文件:", failed)      # ⚠️ 空列表才是全成功

⭐ 这段代码里有四个"看不出问题、但会出错"的点（都是官方参数约束）：

点	官方约束	错了会怎样
`x_dim=1024`	必须与 embedding 模型的输出维度一致	换了模型忘改 → 检索结果莫名其妙变差
`user_id='Default'`	正则 `^[a-zA-Z0-9_-]{6,64}$`	写中文用户名 → 直接报错
`db_path="./sql.db"`	禁用路径含 `/etc` `/usr/bin` `/sys/` `/dev/` `/sbin` `/tmp`；不能是软链接、不能含 `..`	报路径非法
`failed`（返回值）	返回的是失败列表，不是成功列表	只看到"没报错"就以为灌进去了

两条"跑之前先验"的命令：

命令　python3 -c "import mxRag; print('RAG SDK import: OK')"

含义：验证 RAG SDK 的 Python 包能被导入 —— 跑任何代码前的第一道门 拆解：python3 -c（不写文件，直接执行后面这串代码）＋ import mxRag（导入 RAG SDK）用法：直接执行期望：打印 RAG SDK import: OK 不过会怎样：报 ModuleNotFoundError → 没装（回 G3 第四段）或环境变量没生效（重开终端 / source ~/.bashrc） ⚠️ 注意：这条只证明"能 import"，不证明能在卡上跑

命令　ls <embedding模型路径>

含义：确认 embedding 模型文件真的在这台机器上 —— 最常见的"检索查不出东西"就是从这来的 拆解：ls（列出目录内容）＋模型目录路径用法：ls /path/to/model（路径对应环境变量 MX_INDEX_MODELPATH）期望：列出模型文件（权重、配置等）；目录不为空 不过会怎样：报 No such file or directory → 模型没搬进来（私有化环境高发）；目录是空的 → 只建了目录没放模型

命令　npu-smi info -t board -i 0

含义：查第 0 号设备的板卡信息 —— 顺带能读出驱动版本和固件版本 拆解：-t board（查什么：板卡信息）＋ -i 0（查哪台：设备 0）用法：npu-smi info -t board -i 0 期望：输出里 Software Version = 驱动版本；Firmware Version = 固件版本 不过会怎样：-i 后面填错设备号 → 报设备不存在；先用 npu-smi info -l 查有哪些设备 为什么要查这条：RAG SDK 依赖驱动固件版本，环境不对时先确认底座

怎么知道"检索真的起作用了"（这一步只能靠对比）：

问法	期望	说明
用文档里的原句问	返回的 context 里含那段原文	验证链路通了
换一种说法问同一件事	也返回那段	验证不是靠关键词硬匹配
问一个只有这份文档能答的问题	答对	⭐ 这才证明 RAG 起作用
问一个文档里完全没有的事	应该答"不知道"	验证没有编（幻觉控制）

⭐ 最后一行是最容易被忽略的一条：RAG 做坏了不只是"查不到"，还有一种失败是"查不到也硬答" —— 用文档外的问题测一下，看它会不会编。

4.1 官方《开发流程》把整个过程分成两大块：

┌───────────────────── 主线一：构建知识库 ─────────────────────┐
│  ① 上传领域文档 → 加载和切分  → 得到 chunks                  │
│  ② 文本向量化                → chunks 变成向量               │
│  ③ 初始化知识库管理          → 关系库 + 向量库就位            │
└──────────────────────────────────────────────────────────┘
                              ↓
┌───────────────────── 主线二：在线问答 ───────────────────────┐
│  ① 初始化缓存（可选）        → 命中就直接返回                 │
│  ② 初始化大模型 Chain        → 把 LLM/检索/精排串起来         │
│  ③ 初始化检索方式            → 问题向量化 → 找到 context      │
│  ④ reranker 精排（可选）     → 提高检索质量                   │
│  ⑤ 组装 prompt → 传给大模型  → 出答案                        │
└──────────────────────────────────────────────────────────┘

⭐ 两条主线的关系：主线一是"离线"的（建库），主线二是"在线"的（答问）。 官方特别说明：「知识库构建和在线问答支持并发」—— 意思是这两件事可以同时进行，不用停服务来更新知识库。

4.1 主线一 · 第 ① 步：上传文档、加载和切分

官方原文：

上传领域文档，加载和切分。初始化文档处理器，用户可以根据上传的文件类型注册相应的文档解析器 和文档切分器，支持的文档类型包括 Docx、Excel、Pdf、PowerPoint 等。用户可以根据需要加载相应的解析和切分功能，输出为文档切分后的文本 chunks。

这一步的产物叫 chunk（文本块） —— 后面所有事情都基于它。

⭐ 关键概念：为什么要"切"？

因为这个 chunk 将来要被检索出来、塞进 prompt 给模型看，而模型能一次看的内容是有上限的（这个上限叫上下文长度）。 整本书塞不进去，所以要先切成小块，将来只取相关的那几块。

⚠️ 切分粒度是 RAG 效果的第一大变量（G4 展开），本课记住这是第一步就该想清楚的事。

4.2 主线一 · 第 ② ③ 步：向量化 + 两个数据库

官方原文：

文本向量化。加载 embedding 模型，根据模型具体路径进行配置。文档切分后的文本 chunks 向量化后存入知识库管理中的向量数据库。

初始化知识库管理，包括初始化关系数据库和向量数据库。 切分后的文本 chunks 会存入关系数据库，chunks 向量化后数据会存入向量数据库，一一对应。

⭐⭐ 这里有一个很好记的设计：两个库、存两样东西、一一对应

库	存什么	为什么需要它
关系数据库	chunk 的原文	检索是按"意思"找的，但给模型看的必须是原文 —— 不能拿一串数字给它
向量数据库	chunk 的向量	计算机只能比数字，"意思相近"要先变成"距离相近"，这才能算

为什么一定要两个库，一个不行吗：

只有向量库：找到最相似的向量了，但你手里只有一串数，没有原文可以给模型 ✗
只有关系库：原文都在，但没法按"意思"检索，只能按关键词匹配 ✗
两个都有：向量库里查到最近的向量 → 顺着一一对应关系回关系库取原文 → 给模型 ✓

「向量化」在做什么（一句话）：把一段文字变成一串数字， 意思越接近的文字，算出来的数字越接近。

⚠️ embedding 模型是要单独加载的（官方说「加载 embedding 模型，根据模型具体路径进行配置」）—— 它是这套流程里的一个独立零件，不是自动带的。

4.3 主线二 · 第 ① ② 步：缓存与大模型 Chain

官方原文（缓存）：

初始化缓存（可选），RAG SDK 支持配置缓存和近似搜索，当用户问答时优先从缓存中搜索答案，问题命中则直接返回缓存中的回答，未配置缓存或问题未命中缓存则继续以下推理过程。

⭐ 缓存在企业场景的价值：知识库类问答的重复率很高（新人反复问同样的问题）。缓存命中 = 零推理成本，对企业是实打实的算力节省。

官方原文（大模型 Chain）：

初始化大模型 Chain，通过 Chain 串联大语言模型，检索和精排模块进行问答，用户可以选择文生文、文生图、图生图等 Chain，支持多轮对话、检索推理并行等方式。

「Chain」是什么：把「检索 → 精排 → 传给模型」这条流水线串成一个可配置的对象。官方给了多种可选形态（文生文 / 文生图 / 图生图），并支持多轮对话与检索推理并行。

「检索推理并行」值得记一笔：串行的话要等检索完了才开始推理；并行意味着两条路同时走 —— 这是降低延迟的手段（G6 讲容量时会回到这里）。

4.4 主线二 · 第 ③ 步：检索 —— 最容易出问题的一步

官方原文：

初始化检索方式，用户可以定义近似检索、查询改写检索等方式。问题经过 embedding 模型向量化后，通过检索在知识库中找到上下文 context，进行下一步处理。

⚠️ 这一条是本课最该记住的：提升检索质量，官方给了三条路，它们分别在三个位置：

路	在哪个位置动手	官方表述	解决什么
① 查询改写检索	检索前 —— 改问题	「查询改写检索」	用户问法和文档写法不一致（用户说的是口语，文档写的是书面语）
② 近似检索	检索时 —— 换算法	「近似检索」	精确匹配找不到时，按"意思接近"找
③ reranker 精排	检索后 —— 重排序	见下一步	召回来的一堆里，顺序不对，好的排在后面

⭐ 所以检索不是一个动作，是"前—中—后"三个可调点。 大部分 RAG 做出来效果差，问题就出在这里 —— 只用了默认检索，三个调点一个都没动。

4.5 主线二 · 第 ④ ⑤ 步：精排与组装

官方原文（精排）：

对检索到的上下文 context 通过 reranker 进行精排（可选），提高检索质量。

官方原文（组装）：

最后将用户问题和上下文 context 组装成 prompt，传入大语言模型。

「精排」和「检索」的区别（一句话）：

检索：从成千上万条里快速捞出一批（宁可多捞，别漏）
精排：对这批逐条细看，重新排序（把最相关的排到最前面）

为什么要两步：一步到位太慢。先粗后精是检索系统的通用做法 —— 粗筛要快（面对全库），精排要准（只面对一小批）。

最后一步「组装成 prompt」意味着：模型的答案质量，取决于你塞给它的 context 质量。 检索错了，后面全错 —— 这就是为什么 4.4 那三个调点最重要。

4.6 ⚠️ 关于「RAG 和微调怎么选」—— 方法层面的归纳，非官方口径

声明：官方文档没有给出 RAG 与微调的对比。以下是我按前面的官方事实归纳的判断框架， 请勿当作官方文档表述引用。

你的知识是什么形态	更合适	依据（来自官方事实）
文档、手册、制度、FAQ —— 有原文可查	RAG	官方说 RAG「通过为大模型接入外部知识库」；答案有原文作依据，可给人看
频繁变动的知识	RAG	官方说 RAG 解决「知识更新速度慢」—— 改库即更新
要求"说得出依据"	RAG	官方说 RAG 解决「答案透明度欠缺」，context 就是依据
一种稳定的话术/风格/格式	微调	这不是"知识"问题，是"习惯"问题 —— 库里没有原文可检索
要模型学会一种新能力	微调	同上

⭐ 一句话判断法：

「这件事有原文可查吗？」 有 → RAG（把原文找出来给模型看）；没有（是种习惯/能力）→ 微调。

并且这两者不冲突：先上 RAG，不够再微调 —— 因为 RAG 便宜、可回退、可解释（官方说 RAG「以较低成本」）。

⚠️ 微调在现有体系里是空白：官方有 MindSpeed LLM（含《单样本微调》），但它属于官方四大场景里的「训练开发」，与本体系 A–G 的推理主线不同 —— 计划单开 H 层「模型定制」来讲，本课不展开。

第五段怎么确认就位

⚠️ 本节给的是"结构自检"，不是可复制的部署命令。 RAG SDK 的接口调用方式随版本变动，具体命令与参数请查官方《接口参考》 —— 本体系的数据纪律：命令必须来自官方，不能推测性补充。

按四条自检（每条都能用眼睛看到）：

#	检查什么	怎么看	期望
①	文档解析到了吗	看切分后 chunk 的数量和内容	chunk 数不为 0，内容是可读文本（不是乱码/空）
②	向量化成功了吗	看向量数据库里有没有数据	向量库里的条数 = chunk 数（一一对应）
③	检索能返回东西吗	提一个知识库里明确有答案的问题	返回的 context 里含那段原文
④	模型答对了吗	同上问题的最终答案	答案与该原文一致，不是模型自己编的

⭐ 第 ④ 条有个陷阱：模型答对了，不代表 RAG 起作用了 —— 可能它本来就知道（比如问「中国的首都是哪」，答对跟知识库没关系）。测法：问一个知识库里独有的问题（比如你公司内部的报销额度），这种问题模型不可能凭训练数据答对 —— 答对了才证明 RAG 通了。

这条与 D2 的教训同理：官方文档里也提过，"空的返回不算推理成功" —— 验证要看"本该有内容的地方有没有内容"，不能看"有没有报错"。

第六段判据 / 验收

#	判据	验证方式	不过说明
①	文档进得去	上传你公司的一份真实文档	解析器不支持该格式，或格式里有解析不了的元素
②	两个库对得上	关系库 chunk 数 = 向量库条数	向量化环节有问题
③	检索找得回	用文档里原句去问	向量化或检索配置有问题
④	用自己的话也找得回	用换一种说法问同一个问题	需要上「查询改写检索」
⑤	答案有依据	看返回的 context，能不能对上答案	模型在自由发挥（幻觉），prompt 组装环节要改
⑥	换个人问，答得也对	让同事用他的说法问	这条是灵魂 —— 只有你自己能问出来的效果不算效果

第 ⑥ 条是本课的差异化：RAG 最典型的失败是「演示时很好，上线后没人用」—— 因为做的人知道自己该怎么问。换人测，才算真的测过。

第七段出问题怎么查

排查顺序：按两条主线倒着查 —— 先确认"答案该有的依据进没进去"，再看"检索找没找到"，最后才怀疑模型。

你看到的现象	先归到哪一步	先查什么
传了文档，chunk 数是 0	主线一 ①	文档格式解析器注册了没有；文件是不是空的/加密的
chunk 数是 0 但文件没问题	主线一 ①	切分器配置（切分参数不合理可能切不出内容）
chunk 有，向量库是空的	主线一 ②	embedding 模型加载了没有（它要单独配路径）
两个库条数对不上	主线一 ②	向量化有没有中途失败（看日志）
检索总是返回不相关内容	主线二 ③	三个调点：先试查询改写，再看近似检索参数
检索回来的东西是对的，但排在后面	主线二 ④	reranker 精排没开（官方标"可选"，但效果差时它就是必开）
检索对了，答案还是编的	主线二 ⑤	prompt 组装 —— context 有没有真的塞进去；指令有没有要求"只依据上下文回答"
同一个问题反复问，答案不一样	主线二 ①	缓存没配（配上能稳定 + 省算力）
一上多轮对话就乱	主线二 ②	Chain 选型（官方支持多轮对话，要选对形态）
接口报错说权限不够	流程之外	官方明确：RAG SDK 不含用户/权限 —— 这是你要自己做的事（G7）

第八段常见报错清单

⚠️ 本课的报错以"流程性错误"为主，官方未单独收录 RAG SDK 的报错清单。 遇到具体报错，用官方案例库按现象检索：https://www.hiascend.com/document/caselibrary —— 不要按"RAG"检索（那不是一个官方案例分类词）。

现象	属于	先查什么
文档加载失败	主线一 ①	文件类型（官方支持 Docx/Excel/Pdf/PowerPoint 等）、解析器是否注册
切分结果异常（一块巨大 / 全是碎片）	主线一 ①	切分器参数；这一步决定后面所有效果
向量化报错	主线一 ②	embedding 模型的路径配置（官方说「根据模型具体路径进行配置」）
检索无结果	主线二 ③	向量库空不空 → 再查检索方式配置
检索结果相关性差	主线二 ③④	依次：查询改写 → 近似检索 → reranker
答案与 context 无关	主线二 ⑤	prompt 组装；Chain 选型
多轮对话上下文丢失	主线二 ②	Chain 形态是否支持多轮
用例跑不起来，报权限错误	环境	官方明确：「运行阶段请使用 root 用户执行相关用例」

最后一条是官方原文里的一句话，很实用：「运行阶段请使用 root 用户执行相关用例。」 ⚠️ 但这只是"跑官方用例"的要求，不是"生产环境也该用 root" —— 生产环境用 root 跑服务是另一回事，别把用例要求当成部署规范。

第九段小结 + 钩子 + 自测

三句话记住本课

大模型的三个毛病（准确性不足 / 知识更新慢 / 答案不透明），RAG 用"接外部知识库"一次性绕过。 官方原话：RAG 是提升「最后一公里」落地效果的关键技术。
RAG 是两条主线：构建知识库（切分 → 向量化 → 两个库）与在线问答（缓存 → Chain → 检索 → 精排 → 组装）。 两个库一一对应：关系库存原文，向量库存向量。
检索有"前—中—后"三个调点（查询改写 / 近似检索 / reranker 精排）—— 只用了默认检索的 RAG，效果一定不好。

自测（不看上文）

官方说大模型的三个毛病是什么？RAG 分别怎么绕过？
为什么要两个数据库？只留向量库行不行？
检索质量的三个调点分别在哪个位置？
官方 RAG SDK 明确不负责什么？这对你的项目意味着什么？
怎么测才知道「RAG 真的起作用了」而不是「模型本来就知道」？

钩子：下一课

本课讲了 RAG 的整体结构，但主线一的第一步（切分）我们只说了"这件事决定后面所有效果"，没展开。

一份 200 页的 PDF，切成多少块、每块多大、怎么切才不会把一句话切断？ 切出来的块存进两个库以后，怎么管理它们？文档更新了怎么办？

这就是 G3 知识库搭建 —— 会把主线一那三步拆开讲透。

再往后：G4 检索调优 → G5 效果评测 → G6 容量与成本 → G7 企业安全。 微调（MindSpeed LLM）计划单开 H 层。合规部分按你的安排另出文章。

附录 A 官方出处

#	内容	官方出处
1	RAG 的三个毛病与定位：大模型面临准确性不足、知识更新速度慢、答案透明度欠缺；RAG 通过接入外部知识库提升了问答系统准确率，解决了幻觉和时效性问题；「RAG 技术能够以较低成本将基础大模型转换为领域专用大模型，成为提升大模型"最后一公里"落地应用效果的关键技术」	MindSDK 26.1.0《RAG SDK · 简介》→ `zh/mindsdk/2610/rag/ragug/docs/zh/introduction.md`
2	RAG SDK 是什么：「昇腾面向大语言模型的知识检索增强开发套件」；提供向量模型垂域微调数据生成、检索、知识管理等接口；「不包含用户、权限等和业务强相关的功能接口」	同上
3	三项主要功能：快速搭建（模块化接口 + 预置端到端工作流模板 + 极少量代码）/ 多模态解析（文档、表格、PDF、图片）/ 高性能推理（昇腾亲和模型优化加速）	同上
4	开发流程 · 构建知识库：上传领域文档加载和切分（注册文档解析器与切分器，支持 Docx、Excel、Pdf、PowerPoint 等，输出 chunks）→ 文本向量化（加载 embedding 模型，按模型具体路径配置）→ 初始化知识库管理（初始化关系数据库与向量数据库）	MindSDK 26.1.0《RAG SDK · 开发流程》→ `…/docs/zh/user_guide.md`
5	双库一一对应：「切分后的文本 chunks 会存入关系数据库，chunks 向量化后数据会存入向量数据库，一一对应」	同上
6	开发流程 · 在线问答：初始化缓存（可选，支持配置缓存和近似搜索，命中直接返回）→ 初始化大模型 Chain（串联 LLM/检索/精排，可选文生文、文生图、图生图，支持多轮对话、检索推理并行）→ 初始化检索方式（可定义近似检索、查询改写检索）→ reranker 精排（可选，提高检索质量）→ 组装 prompt 传入大模型	同上
7	并发与运行要求：「知识库构建和在线问答支持并发」；「运行阶段请使用 root 用户执行相关用例」	同上
8	微调的官方对应物	MindSpeed 26.1.0《MindSpeed LLM · 大语言模型套件》（含《单样本微调》）

⚠️ 本体系中属于「归纳/方法」而非官方原文的部分，已明确标注： - 第 4.6 节《RAG 与微调怎么选》 是方法层面的归纳，官方文档没有这个对比； - 第五段的「结构自检四条」（尤其第 ④ 条"用自己的话测"）与第六段验收表，属实践方法； - 4.1 关于「为什么要切分」的解释（上下文长度限制）属通识说明，非本 SDK 文档原文。

附录 B 命令详解

本课未使用 Linux 命令。RAG SDK 的操作通过代码接口完成， 接口调用方式随版本变动，按数据纪律不在课件中写死 —— 请查官方《接口参考》中对应版本的章节。

本课涉及的三个概念词（不是命令，一并解释，避免与后续课混淆）：

词	含义
chunk	文档切分后的文本块。它是 RAG 里最小的检索单位 —— 检索找到的是 chunk，给模型看的也是 chunk
embedding	向量化：把文字变成一串数字，意思越接近数字越接近。做这件事的模型叫 embedding 模型
reranker	精排模型：对检索召回的一批结果重新排序，把最相关的排到最前。与 embedding 是两个不同的模型

昇腾部署第 G2 课：RAG 基础——企业为什么要私有知识库，两条主线是什么

第一段 章前定位

第二段 学习目标

第三段 全景：RAG 要解决什么

3.1 官方点名的三个毛病

3.2 官方的定位原话（这句是这课的题眼）

3.3 官方给 RAG SDK 的边界（这段话决定了它是不是你要的东西）

第四段 【如果我来做】从接到需求到跑通最小链路

4.0 我会按这个顺序走（顺序错了会白干）

4.0.1 最小可跑链路（20 行，先跑通再优化）

4.1 官方《开发流程》把整个过程分成两大块：

4.1 主线一 · 第 ① 步：上传文档、加载和切分

4.2 主线一 · 第 ② ③ 步：向量化 + 两个数据库

4.3 主线二 · 第 ① ② 步：缓存与大模型 Chain

4.4 主线二 · 第 ③ 步：检索 —— 最容易出问题的一步

4.5 主线二 · 第 ④ ⑤ 步：精排与组装

4.6 ⚠️ 关于「RAG 和微调怎么选」—— 方法层面的归纳，非官方口径

第五段 怎么确认就位

第六段 判据 / 验收

第七段 出问题怎么查

第八段 常见报错清单

第九段 小结 + 钩子 + 自测

三句话记住本课

自测（不看上文）

钩子：下一课

附录 A 官方出处

附录 B 命令详解

第一段章前定位

第二段学习目标

第三段全景：RAG 要解决什么

第四段【如果我来做】从接到需求到跑通最小链路

第五段怎么确认就位

第六段判据 / 验收

第七段出问题怎么查

第八段常见报错清单

第九段小结 + 钩子 + 自测