GYR（Get Your RAG） on Renxin's Blog

第一话｜大模型会聊天，但怎么让它知道你的退货政策？

Fri, 21 Aug 2026 00:00:00 +0000

“NovaTrail X2 支持 7 天无理由退货吗？”

把这个问题交给一个裸大模型，它大概率会给出一段很像客服的话：商品需要保持未使用、包装完整，并保留购买凭证。

听起来没什么问题。

但它不知道 NovaShop 的真实退货政策。它没有看过这份商品资料，不知道规则适用于哪个地区，也不知道政策是不是昨天刚刚改过。

它只是生成了一段听起来合理的文字。

这就是 RAG 系列要解决的起点：大模型虽然会聊天，但它不知道你的退货政策。

一、裸大模型：会生成答案，但没有企业知识

先不谈 RAG，看看最原始的系统是什么样：

用户问题 → Chat 模型 → 文本回答

这类模型可以翻译、总结、写代码，也能把客服话术写得很自然。但它的回答依赖两类输入：训练时学到的参数知识，以及本次请求中传入的上下文。

企业自己的商品政策、内部流程、最新价格和租户数据，通常不在它能够直接访问的上下文里。模型并不会因为“你是 NovaShop 客服”这句话，就自动获得 NovaShop 的资料。

所以裸模型的第一个边界很清楚：它可以生成企业知识问答的语言，却没有企业知识问答的证据。

二、第一种补救：把资料塞进 Prompt

最简单的办法，是把政策直接放进提示词：

你是 NovaShop 客服。
以下是退货政策：
NovaTrail X2 支持签收后 7 天内无理由退货，商品须未使用、包装完整，并保留配件和购买凭证。

请根据这段政策回答用户的问题。

这个办法确实有效。模型现在能看到资料，也能根据资料生成回答。

问题是，企业资料不会永远只有一段。商品规格、物流规则、保修政策、不同地区的退货政策和新旧版本都会继续增加。最后，Prompt 会变成一份越来越长、越来越难维护的知识文档。

当回答出错时，排查也很困难：资料没有放进去？放进去了但没有检索到？检索到了但模型没有使用？还是引用了已经过期的版本？

Prompt 方案解决的是“把资料放到模型眼前”，却没有解决“资料如何管理、如何查找、如何证明回答有依据”。

关键洞察： Prompt 可以临时装下知识，但不能替代一条可维护、可追溯的知识链路。

三、第二种补救：先检索，再生成

RAG 在 Prompt 方案前面增加了一步：模型回答之前，系统先去资料中找相关内容。

用户问题
 ↓
检索相关资料
 ↓
组装上下文
 ↓
Chat 模型生成回答
 ↓
返回引用或拒答

这条链路可以拆成五个动作：

动作	要回答的问题
文档准备	企业资料从哪里来？
检索	哪些片段和当前问题有关？
上下文组装	哪些内容真正交给模型？
生成	模型是否只根据这些内容回答？
引用与拒答	能否指出依据，证据不足时能否不回答？

RAG 原始论文把外部检索到的知识接入生成过程，用来缓解参数知识难以更新、访问和追溯的问题。Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

这里还要先纠正一个常见误解：RAG 不等于向量数据库。 Retriever 可以使用关键词检索、Elasticsearch 的分词器和倒排索引、向量检索、结构化查询，也可以把几种方式组合成混合检索。本系列会在后续文章里分别比较这些方式；本篇只把“检索”当作一个黑盒步骤，不展开它的内部算法。Elasticsearch，Search approaches

四、从最小 RAG 到企业级知识助手

RAG 让模型“回答前先查资料”，但这还只是企业知识助手的中间一层。真正的系统需要沿着两条链路运行。

1. 文档入库链路

企业资料不是凭空出现在检索器里的，它要先经过入库：

文档上传
→ 解析与清洗
→ 分块
→ 建立索引
→ 保存版本和来源

这一条链路解决的是“系统手里到底有什么资料”。文档解析决定哪些内容能被看见，分块决定检索的最小单位，索引决定怎么找到它们，版本和来源决定答案能不能回溯。

2. 问答链路

用户提问时，系统再走另一条链路：

用户问题
→ 检索候选片段
→ 权限与版本过滤
→ 组装上下文
→ 模型回答
→ 引用、拒答与记录

两条链路合起来，才是企业级 RAG 的基本轮廓：

%%{init: {'theme':'neutral'}}%%
flowchart LR
 A["企业文档"] --> B["解析与索引"]
 B --> C["检索"]
 D["用户问题"] --> C
 C --> E["上下文与模型"]
 E --> F["回答与引用"]

这张图只画了主链路，没有画出所有生产组件。评测、权限、版本、任务恢复和观测会横向影响多个节点，后面分别展开。

五、跑一次全链路预览

理论地图有了，接着跑最小实现。配套代码目前保存在私有工作区的 code/agent-tutorial/c01-rag-overview/，尚未作为公开代码仓库发布；实验只依赖 Python 3.10+ 标准库。云端运行需要百炼兼容模式的 DASHSCOPE_API_KEY。

cd code/agent-tutorial/c01-rag-overview
export DASHSCOPE_API_KEY=你的Key
python3 main.py

本次预览实验使用阿里云百炼：

角色	模型
Chat	`deepseek-v4-flash-0731`
Embedding	`qwen3.7-text-embedding`

没有 Key 时，可以先验证本地链路：

python3 main.py --offline
python3 -m unittest discover -s tests -v

离线模式只验证这条链路的数据结构、上下文组装和引用格式，不代表云端模型的回答效果。云端跑通的判定标准是：看到模型配置、命中的来源、上下文字符数、回答，以及形如 [source:returns-cn#chunk-001] 的引用。至于系统为什么会把某些片段排在前面，下一篇再拆开解释。

2026-08-21 的一次真实运行结果如下：

{"mode":"dashscope","provider":"aliyun-bailian","chunks":3,"chat_model":"deepseek-v4-flash-0731","embedding_model":"qwen3.7-text-embedding"}
{"question":"NovaTrail X2 是否支持 7 天无理由退货？","sources":["returns-cn#chunk-001","novatrail-x2#chunk-001"],"context_chars":215,"answer":"支持。根据退货政策，NovaTrail X2 可在签收后 7 天内无理由退货，但需满足商品未使用、包装完整、保留配件和购买凭证等条件。 [source:returns-cn#chunk-001]"}
{"question":"NovaShop 是否提供月球基地配送？","sources":["returns-cn#chunk-001","novatrail-x2#chunk-001"],"context_chars":215,"answer":"无法确认。现有资料中未提及月球基地配送服务。"}

上面是从真实输出中保留本篇关心字段后的结果。第一个问题走通了完整链路：系统返回了相关来源，模型根据上下文回答，并附上了来源标记。至于这些来源如何被计算和排序，本篇先不展开。

第二个问题暴露了当前 Demo 的边界。资料里没有月球基地配送，但系统还是返回了两个候选片段，因为程序现在固定返回若干候选。模型这次回答“无法确认”，但无关片段已经进入上下文；换一个问题，模型可能会被这些噪声影响。

这说明“能检索、能生成”还不等于“知识助手可靠”。我们还需要阈值、评测、引用校验和拒答策略。

如果运行失败，先看错误发生在哪一层：DASHSCOPE_API_KEY is not set 表示当前 Shell 没有读到 Key；401 或 403 通常是 Key 无效、过期或没有权限；404 model not found 则要检查模型名、地域和百炼工作空间。代码默认使用 aliyun-bailian、deepseek-v4-flash-0731 和 qwen3.7-text-embedding，也可以通过 README 中的环境变量覆盖。

关键洞察： 这个 Demo 的价值不是证明 RAG 已经可靠，而是把“资料从哪里来、系统找了什么、模型看到了什么、回答引用了什么”第一次暴露出来。下一篇，我们再追问“系统为什么找到了这些片段”。

六、GYR 系列接下来会补齐什么

现在可以回头看整个系列的路线。每一篇不是凭空增加一个组件，而是在解决上一层暴露出来的具体问题：

阶段	要解决的问题	主题
第一话	整条链路到底是什么	RAG 全景与演进路线
第二话	问题和文本为什么可以比较	Embedding、余弦相似度、Top-K
第三话	一篇长文应该如何检索	文档分块与 Chunk 设计
第四话	找到资料后如何可靠回答	上下文、引用与拒答
第五话–第六话	如何保存和评价检索结果	PGVector、版本与评测基线
第七话–第八话	关键词和向量如何配合	检索优化与混合检索
第九话–第十二话	企业资料如何进入系统并保持边界	解析、租户权限、任务恢复与观测
第十三话–第十四话	如何收敛为可运行的服务	API、模块化原型与框架对照

这条路线有一个刻意的约束：先手写最小机制，再引入数据库、服务和框架。否则读者很容易得到一个“能启动的 RAG”，却不知道每个组件为什么存在。

下一篇：Embedding 到底做了什么

现在我们知道 RAG 的整体链路，也看到一个最小版本确实可以把问题和资料交给模型。但“检索”仍然像一个黑盒：为什么退货政策排在前面？相似度分数是什么？SKU 这种精确编号也适合这样检索吗？

下一篇只回答一个问题：一句用户问题，为什么可以和一段商品政策计算相似度？

我们会检查 Embedding 的真实输出，手写余弦相似度和 Top-K 排序，把第一话图里的“检索”拆开来看。

第一篇只需要记住一句话：

RAG 是裸大模型走向企业知识助手的第一条外部知识链路，但它远没有替企业完成评测、权限和数据治理。

参考资料

Patrick Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，2020。
Alibaba Cloud Model Studio，List models。
Alibaba Cloud Model Studio，DeepSeek API。
Elasticsearch，Search approaches。

第二话｜怎么根据用户的提问找到相关的退货政策？

Sun, 30 Aug 2026 00:00:00 +0000

“这双鞋七天内能退吗？”

NovaShop 的资料里没有这句话。资料写的是：“NovaTrail X2 签收后 7 个自然日内可申请退货；商品需保持完好且配件齐全。”

两句话说的是同一件事，字面上却对不上。如果助手只会查关键词，这个问题很可能直接被漏掉——用户不会觉得是“没搜到”，只会觉得这个助手不懂人话。

这一话就把这次匹配拆开，看三件事：问题怎样变成数字，三条政策怎样被排出先后，以及“排第一”到底意味着什么。

先别急着谈向量

先准备三段极小的候选资料：

标识	候选片段
`return-policy`	NovaTrail X2 签收后 7 个自然日内可申请退货；商品需保持完好且配件齐全。
`shipping-policy`	NovaTrail X2 标准配送通常在付款后 1 至 3 个工作日发货，偏远地区时效可能延长。
`size-guide`	NovaTrail X2 提供黑色 M 码与 L 码；下单前请参考尺码表确认脚长。

如果只做关键词匹配，“七天内能退”里的“退”，和资料里的“申请退货”，靠的是同一个意思，而不是同一个词。想接住这种说法，传统做法是在词表里补同义词规则——把“退”“寄回去”“不合适”都映射到“退货”上。

规则不是没有价值。SKU、订单号这类精确标识，恰恰适合这种方式：用户原样报出“NS-X2-BLK-M”，关键词匹配又快又准。

可客服问题远不止 SKU 和订单号。用户会说“能退吗”“不喜欢能不能寄回去”“尺码不合适怎么办”，把每种说法都写进词表，维护成本很快失控。

Embedding 换了个思路：不比字符串，先把文本变成一串数字（向量），再比较两段文本在这个空间里离得近不近。阿里云百炼把 Embedding 定义为把文本等数据转换为数值向量，用于语义搜索等下游任务。官方文档

系统比较的到底是什么

候选政策可以提前编码、保存。用户发来问题时，系统只需要编码这一个问题，再拿它和候选向量逐个比较。

检索先找“该看哪几段”，回答环节再决定怎样组织答案。

这里有三件事不能混：

查询和候选片段必须用同一个 Embedding 模型编码，否则两者未必落在同一套表示空间里。
参与比较的两条向量必须等长；维度不同，余弦相似度无从算起。
得到的只是当前候选集合里的排序，不是“答案正确率”。

这很像 Java 里的 Comparator：它能给对象排出先后，却不会替你判断“排第一的就是正确答案”。向量分数也一样——只负责排队，不负责下结论。

密集检索的通行做法，就是分别编码问题和文本片段，再用相似度挑选候选上下文，DPR 论文用的正是这种双编码器思路。Karpukhin 等，2020 我们选余弦相似度，只是为了把计算摊开看，不代表所有检索系统都这么算。

相似度怎么算

候选片段和查询都变成了向量，“近不近”就变成了数值比较。那这个数值具体怎么算？这一节用余弦相似度回答。

$$ \operatorname{cosine}(q,d)=\frac{q \cdot d}{\lVert q \rVert\lVert d \rVert} $$

q 是查询向量，d 是一条候选片段向量。分子把两个向量逐维相乘再相加（点积），衡量它们在每个维度上是不是朝同一个方向使劲；分母乘上两个向量的长度，避免“向量长分数就高”。结果有直观的含义：同方向的向量分数接近 1，垂直的接近 0，反方向接近 -1。排序器关心的，就是谁离 1 更近。

余弦公式有两个必须预先处理的边界：两条向量要同维、非零。维度不一致，逐维相乘根本对不上；零向量没有方向，分母一除就崩。排序器在这里主动报错而不是硬算，是为了让配置错误早点暴露，而不是让一个坏分数混进排序。

def cosine_similarity(left: Sequence[float], right: Sequence[float]) -> float:
 """计算两个同维、非零向量的余弦相似度。"""
 if len(left) != len(right):
 raise ValueError("向量维度不一致，不能计算余弦相似度")

 # 点积衡量两个向量在各维度上的同向程度。
 dot_product = sum(a * b for a, b in zip(left, right, strict=True))
 left_norm = math.sqrt(sum(value * value for value in left))
 right_norm = math.sqrt(sum(value * value for value in right))

 # 零向量没有方向；继续计算会产生除零错误，也没有检索意义。
 if left_norm == 0 or right_norm == 0:
 raise ValueError("零向量没有方向，不能计算余弦相似度")

 return dot_product / (left_norm * right_norm)

这一段代码和公式一一对应：先检查输入，再算点积，再算两个长度，最后相除。拒绝分支不是额外负担，它就是“余弦在不同输入上的定义边界”。

只取前 K 名

三个候选都有分数了，接下来怎么挑？答案朴素：按分数从高到低排，取前 K 个。这就是 Top-K 里的“K”。

排序里有一个容易忽略的小决策：分数并列时怎么办。rank_candidates 用原始下标做第二排序键，保证同一份输入反复运行得到同一份顺序——方便测试和复现，但不代表两个并列候选在业务上有高低。

def rank_candidates(
 query_vector: Vector,
 candidates: Sequence[Candidate],
 candidate_vectors: Sequence[Vector],
 *,
 top_k: int,
) -> list[RankedCandidate]:
 """按余弦相似度降序返回前 ``top_k`` 个候选。"""

 if len(candidates) != len(candidate_vectors):
 raise ValueError("候选片段数量与候选向量数量必须一致")
 if top_k <= 0:
 raise ValueError("top_k 必须大于 0")

 ranked_with_index = [
 (index, RankedCandidate(candidate, cosine_similarity(query_vector, vector)))
 for index, (candidate, vector) in enumerate(zip(candidates, candidate_vectors))
 ]
 ranked_with_index.sort(key=lambda item: (-item[1].score, item[0]))
 return [item[1] for item in ranked_with_index[:top_k]]

RankedCandidate 只是把候选片段和分数绑在一起的容器。真正的逻辑只有三步：逐条算分数、按分数降序排（分数打平看原始下标）、切片取前 top_k。

用一个玩具例子看：查询向量 [1.0, 0.0]，三个候选向量是 [1.0, 0.0]、[2.0, 0.0]、[0.0, 1.0]，分数分别是 1.0、1.0、0.0。取 top_k=2，结果是前两个候选——同分时保住原始顺序，第三个出局。

先把本地验证跑起来

排序逻辑不依赖云端，验证也先离线做。运行：

cd /Users/renxin/ai_brain/GYR
python3.11 -m unittest discover -s c02-embedding-topk/tests -v

测试喂的全是固定小向量，把排序器的不变量直接写进断言：同方向向量 [3.0, 4.0] 和 [6.0, 8.0] 的余弦必须是 1.0；并列分数的三个候选取前两名必须稳定得到 first、second。

self.assertAlmostEqual(cosine_similarity([3.0, 4.0], [6.0, 8.0]), 1.0)

results = rank_candidates(
 [1.0, 0.0],
 candidates,
 [[1.0, 0.0], [2.0, 0.0], [0.0, 1.0]],
 top_k=2,
)
self.assertEqual([result.candidate.chunk_id for result in results], ["first", "second"])

这次实际运行 4/4 通过：同向向量、零向量拒绝、维度不一致拒绝、并列分数稳定排序。

为什么坚持先离线验证？因为云端调用不可重放——每次可能在小数后几位漂移，还要消耗配额；而排序逻辑是确定性的，它该在本地一次测对。云端只负责一件事：把文本变成向量。

接上真实模型

本地排序器验证完毕，现在把玩具向量换成百炼 Embedding 的真实输出。接云端要做三件事：设环境变量、跑 main.py、看输出。

请求走的是 OpenAI 兼容接口的 /embeddings：把模型名和输入文本发过去，拿回一串浮点数。Base URL 和 API Key 从环境变量读取，不要写进代码、文章或 Git。

export DASHSCOPE_API_KEY='你的密钥'
export DASHSCOPE_COMPATIBLE_BASE_URL='https://你的业务空间域名/compatible-mode/v1'
python3.11 c02-embedding-topk/main.py --top-k 3

这次真实运行（模型 qwen3.7-text-embedding，请求 1024 维、实际返回 1024 维）的输出是这个形状，以第一个问题为例（候选正文为排版截断，分数与排序未改）：

model=qwen3.7-text-embedding
requested_dimension=1024
actual_dimension=1024

query=这双鞋七天内能退吗？
1. return-policy	score=0.650210	NovaTrail X2 签收后 7 个自然日…
2. shipping-policy	score=0.445476	NovaTrail X2 标准配送通常在付款后…
3. size-guide	score=0.418887	NovaTrail X2 提供黑色 M 码与 L 码…

模型、地域和业务空间配置都可能变化，接入时以你的控制台和官方接口说明为准。

这里有一个容易忽略的边界。main.py 把“候选片段”和“用户问题”分成两批请求，代码里保留了 document 与 query 两种角色，这是为了对齐百炼“检索任务建议区分查询和文档”的惯例；但我们这次用的是 OpenAI 兼容模式，接口里没有对应的角色字段——本地变量叫 query，不代表服务端真的按“查询模式”去编码。

跑出来的结果：直觉对了，边界也露出来了

三个问题都跑完，Top-1 汇总如下：

用户提问	Top-1 候选	分数	能说明什么
这双鞋七天内能退吗？	`return-policy`	0.650210	这次口语化退货问题把退货片段排在第一。
下单后多久能发货？	`shipping-policy`	0.614013	换成物流问题后，同一候选集的第一名随之变化。
NS-X2-BLK-M 什么时候发货？	`shipping-policy`	0.686929	“发货”语义占了主导；不能据此证明 SKU 精确检索可靠。

顺带说明：同一模型、同一候选集，分数会在第四位小数附近轻微漂移，这正是“分数不能当阈值”的一部分。以上面这次运行为准。

第三行最容易让人误判。“NS-X2-BLK-M 什么时候发货”确实把“发货政策”排到了第一，看着像答对了方向；可候选资料里根本没有这件 SKU 的发货记录。这个结果只能说明“发货”两个字在语义上占了上风，证明不了 SKU 检索可用。

分数能做什么、不能做什么

开篇承诺的三件事，到这里都能回答了：问题是怎样变成数字的（Embedding），三条政策是怎样排出先后的（余弦相似度 + Top-K），排第一意味着什么——它意味着“在当前候选集合里最靠前”，仅此而已。

Top-K 的作用很朴素：把后续要看的资料缩小到几段。至于分数本身，别指望它替你判断下面这些事：

不能直接据此判断	原因
最终答案正确	回答仍可能误读、遗漏或编造候选内容。
证据足够	高分只表示相对靠前，不代表覆盖了回答所需条件。
可以忽略精确词	SKU、订单号、政策版本等字段常需要过滤或关键词能力补充。
一个分数阈值通吃	分数依赖模型、候选集合、切分方式和相似度定义。

一句话收束：排第一不等于答案可信。 0.65 只说明“退货片段排在最前”，不说明“这条退货规则就是答案”。所以 Agent 的检索工具到这里就该停下——它交回候选证据和来源，而不是把分数包装成“答案可信”。之后的回答、过滤、引用、拒答，仍然是编排层要承担的事。

结尾：一整篇政策，只有一个分数

前面用到的候选都是精心切成一段的小文本。如果候选本身就是一整篇长政策呢？我们把退货政策扩成六个条款：

NovaTrail X2 退货政策：签收后 7 个自然日内可申请退货；商品需保持未使用状态、包装完整，并保留全部配件与购买凭证；因商品质量问题退货时，运费由 NovaShop 承担，退款将在收货后 3 个工作日内原路退回；因个人原因（尺码、喜好等）退货时，运费由买家承担；特价清仓商品与定制商品不支持无理由退货；运输途中损坏的商品可以申请换货。

问它：“鞋收到是坏的，退货运费谁出？”（环境变量沿用上一节，运行 main_long_policy.py）

这次的真实结果：

-- 整篇政策作为一个候选（整篇只有一个分数）--
1. return-policy-full	score=0.585282	NovaTrail X2 退货政策：…

-- 同一篇政策拆成条款逐条打分（预告第三话的切分视角）--
1. clause-4	score=0.708807	因个人原因（尺码、喜好等）退货时，运费由买家承担；
2. clause-3	score=0.697954	因商品质量问题退货时，运费由 NovaShop 承担，退款将在收货后 3 个工作日内原路退回；
3. clause-6	score=0.675624	运输途中损坏的商品可以申请换货。

整篇政策只有一个分数 0.585282——我们只知道“这篇政策相关”，却不知道是哪个条款把它顶上去的。拆成条款后，三条与“运费/损坏”相关的条款全部浮到前面，定位明显变细。

这里还有一层诚实的噪声：排第一的是条款 4（“个人原因，买家承担”），而不是条款 3（“质量问题，NovaShop 承担”）。“坏的”按语义应该指向质量问题，但“运费谁出”的表层表达把条款 4 顶了上来。也就是说：分块让“哪一段相关”变得可见，但并没有让排序变成正确——检索找到候选是一回事，候选能不能支撑回答是另一回事，那要等后面的章节处理。

第二话到这里，检索单元的粒度问题就摆上台面了：一整篇政策只算一个候选片段，粒度还是太粗。长文档到底该切成多大一块，才能既找得到规则，又不丢掉规则的上下文？