Prompt工程 on 老朱的赛博工位

RAG 改写没头绪？6 规则配 6 类型直接抄

Thu, 15 Oct 2026 13:00:00 +0800

上一篇拆了 Query 改写的链路：四步+两道短路。这篇补核心对照——六条规则对应六种问法，一类问题开一剂药。

为什么先分类再改写

病症不同，药不同。不分类一刀切地「请改写用户问题」，模型容易改错方向：把该放行的独立问题改花，把对比句「归纳」掉一个实体。我的做法是把六规则和六类型全部写进 system prompt，模型每步输出 JSON {type, rewritten}——先判型，再按规则改。

真实 prompt 关键段（query-rewrite.service.ts，节选）：

先判断 query 类型（从以下选一个）：
- context_dependent: 上下文依赖型（需看历史才能理解指代）
- comparative:       对比型（A 和 B 哪个好）
- vague_reference:   模糊指代型（那个东西怎么用）
- multi_intent:      多意图型（同时问多个事）
- rhetorical:        反问型（难道不是...吗）
- standalone:        独立型（不依赖历史，表达清晰）

只输出 JSON，不要解释，不要 markdown：
{"type": "类型", "rewritten": "改写后的完整query"}

模型 deepseek-chat，temperature: 0.1（改写要确定性），response_format: json_object。

六组配对：症状 → 药

类型	症状	用药
context_dependent	「那第二步呢」，缺指代缺主语	指代消解 + 省略补全：从 history 把实体拉回来
comparative	一句问两个东西的区别	模糊词具体化，双实体必须同时保留——两个实体就是检索词，去掉任一个都伤召回
vague_reference	「好用吗」「怎么弄」	模糊词具体化：口语翻译成可打分的明确意图
multi_intent	一句话问三件事	多意图聚焦：拆子问题分开检索，整句塞给向量语义直接漂
rhetorical	「这都查不出来？」	反问转意图：情绪化反问转陈述式再去查，原话进检索几乎 0 命中
standalone	句子成分齐全	放行不改。改写成分齐全的独立问题，反而容易改坏

婚假实测（同一组数据贯穿两篇）：

输入：「申请要怎么做?有没有步骤」+ 2 条婚假相关历史
输出：{"type": "context_dependent",
       "rewritten": "婚假申请的具体步骤和流程是什么"}
耗时 709ms / 565 token
BM25 命中：0 条 → 11 条（索引 docs=38, vocab=1936）

一条横六型的护栏：不编造实体

prompt 第 6 条规则单独拎出来说，因为它是事故源头：

6. 不要添加历史中不存在的信息，不要编造实体

rewritten 里只能出现 history 和原问里出现过的实体——用户没提婚假，就不能「猜」他要问婚假。编造实体 = 检索奔向错误文档，比不改更糟。

对比型还有一个专门的坑：模型爱把「A 和 B 的区别」「归纳」成只讲 A。所以规则里写死双实体必须保留，这条救过一次召回。

宁可保守：失败全回 null

改写失败、超时、JSON 不合法、改写结果和原话一样——一律 return null，上层降级用原 query，链路永不因改写挂掉。判型成 standalone 或直接跳过（无历史 / 启发式不含指代信号）都走同一个出口。

保守方向的选择题：改坏了捞错文档 vs 不改多捞几条垃圾——后者至少模型还能自己消化，前者直接把错误资料塞进上下文。所以宁可少改。

速查表（贴墙版）

上下文依赖 → 指代消解 + 省略补全
对比       → 具体化 + 保留双实体
模糊       → 模糊词具体化
多意图     → 拆分逐条检
反问       → 转陈述再查
独立       → 放行不改
公共护栏：不编造实体 + 异常回原话

改改写本质是「先承认用户的问法会带来什么麻烦，再决定怎么改」。无差别套一句「请优化这个问题」的 prompt，最容易跑偏。

本篇最早于 2026 年 10 月 15 日发布于小红书，此为含完整代码与数据的博客版。

RAG 还是微调？大模型应用 3 种模式别选错

Fri, 09 Oct 2026 09:30:00 +0800

做 AI 应用绕不开这道选择题：让模型「懂你的业务」，到底靠提示词、RAG，还是微调？

我把自己的企业知识库项目（Nuxt3 my-nuxt-app：私有制度文档问答，检索走向量+BM25 混合，生成走 deepseek-chat API）从头选到尾，这篇文章把三层的边界和我的决策过程讲清楚——这也是面试被问最多的一题。

先摆认知地基：训练范式在干嘛

一张表说人话（来自我系统补的《语言模型训练范式》课件，老师一句话总结：大模型 = 会接话茬的机器（Pretrain）+ 会做任务的机器（SFT）+ 会自我评判的机器（RM/PPO/DPO））：

阶段	在干嘛	人肉类比	数据量
Pretrain	海量文字学「预测下一个字」	儿童大量阅读	Llama3 用了 15 万亿 tokens
SFT	带标注问答，从接话茬变做任务	老师布置带答案的作业	几十万条 ≈ 预训练的 1/5000
RM + PPO/DPO	学会「说人该说的话」	按批改意见反复改写	较小

硬核数字记一个就够：Llama 3.1 405B 预训练 = 16384 块 H100 跑 54 天，亿级人民币。所以普通企业和个人根本不碰预训练，选择题只在「现成模型 + 什么方式喂能力」之间做。

面试加分项也在这：SFT/微调 ≠ 给模型喂知识，是教模型「做任务」。 知识靠 Pretrain（通用）+ RAG（私有/新）供给。很多人把微调当成「把公司文档灌进模型」，方向从根上就错了。

三层模式，按成本从低到高

第一层：Prompt / 上下文工程

把关键信息直接写进 system prompt。适合：全局规则、输出格式、角色设定。

局限：窗口有限，塞不进几十份制度文档；每轮都重复计费。我的项目里它只负责「只用资料作答、不编造、标注来源页码」这类约束。

第二层：RAG——知识在模型外面

文档入库切块 → 向量化（我用 Chroma + bge-m3）→ 提问先检索（混合检索：BM25+向量，RRF 融合，reranker 精排取 top5）→ 检索结果拼进 prompt → 生成。

知识更新 = 重新入库，分钟级。 文档改了版本，知识库表里状态机走一遍（草稿→发布→下架），不动模型一根手指。回答能带来源文件和页码——可溯源，这是企业场景的硬需求，微调给不了。

第三层：微调——把能力焊进权重

拿几百到几万条「输入→期望输出」对模型做 SFT。适合什么？固定的输出格式、领域语气、术语习惯——也就是「行为方式」，不是「知识内容」。

我的真实三笔账（为什么 my-nuxt-app 选了 RAG，微调碰都不碰）

1. 知识更新频率。 部门制度文档是活的：新考勤规则、修订的报销流程。RAG 重新入库就完事；微调要攒数据、排队训练、验证回归——为「上周改的那条婚假规定」重训一次模型，纯属行为艺术。

2. 机器现实。 我的生产环境是 99 元/年的 2核2G 阿里云 ECS，内存预算排完（nginx 64MB + node-app 384MB + 系统 + swap）只剩 1G 出头。这台机器连一个 7B 模型都推理不动，更别说训练。我架构里所有重活全在云 API：Embedding 走 bge-m3、精排走硅基流动 bge-reranker-v2-m3、生成走 deepseek-chat。微调需要训练数据+算力+评测集三件套，对个人项目是三重成本。

3. 可回滚性。 RAG 答错了，改文档、调分块、调检索参数，改完立刻生效，还能追溯「当时引用了哪一页」。微调把错误知识焊进权重后，你连它为什么胡说都查不出来，回滚要重训。

什么时候我才会上微调

预判一下自己：等业务问答稳定，出现这类需求再考虑——「回答必须严格按公司工单模板的语气和结构输出」这种格式/风格问题。届时也是 LoRA 这类轻量方案 + 现成 API 模型，依旧不碰预训练。知识类需求，永远 RAG。

速查表

需求	选择
全局规则/格式约束	Prompt
私有知识、时效知识、要溯源	RAG
固定输出风格/任务行为	微调（最后才考虑）
「把文档灌进模型」的想法	❌ 方向错了，那是 RAG 的活

一句话收束：知识在模型外面解决（RAG），行为在模型权重里解决（微调）——分不清这两件事，选型必错。

下一篇讲 RAG 效果差怎么调试。

本篇最早于 2026 年 10 月 9 日发布于小红书，此为博客完整版。