本地知识库的大模型提示词模板

本地知识库搭起来了，检索也能返回几段文档，但模型答出来的东西经常没出处、爱编、还答非所问。问题多半不在检索，在喂给模型的提示词没写清该干什么。这篇把检索问答场景常用的几类模板拆开讲：每个位置写什么、什么情况下不适用、怎么用你自己的文档试出差别。

本地知识库搭起来了，检索也能返回几段文档，但模型答出来的东西经常没出处、爱编、还答非所问。这时候很多人第一反应是去调检索，改分块、换向量模型、加关键词权重，折腾一圈发现召回其实没问题。问题多半不在检索，在喂给模型的那段提示词根本没写清该干什么。

本地知识库的问答跟普通聊天是两种任务。普通聊天靠模型脑子里记的东西，知识库问答靠你临时塞进去的那几段文本。模型不会自动知道你只给了它这么点材料，它会拿训练时记住的内容补上，读起来通顺，其实一句依据都没有。这篇把检索问答常用几类模板拆开讲：每个位置写什么、什么情况下不适用、怎么用你自己的文档试出差别。

为什么直接问模型会答飞

检索返回三五段文本，你拼成一句话丢给模型：「根据以下内容回答问题：……」。模型看到这个指令，会把它当成一个参考，而不是唯一来源。它手里的材料只覆盖了问题的一部分，剩下的空档它会用自己记住的东西填。填对了算运气，填错了你还找不出是哪一步出的问题。

• 把检索到的内容和自己印象混着说，你没法判断哪句有依据
• 答不上来也硬答，明明材料里没写，它还是给你编一段像样的回答
• 引用了但没说清哪句话出自哪一段，你回头核对要重新翻一遍原文
• 材料里的数字、名称被悄悄改掉，跟原文对不上，这种最难发现

这三种翻车的根子是同一个：你没告诉它边界在哪。边界不是「请准确回答」这种话能划出来的，得靠具体的槽位和格式约束。什么情况下这套判断不适用？如果你本来就是想让模型结合行业常识做开放讨论，那它补内容是合理的，这时候不该用带引用约束的模板，后面会单独讲。

提示词里必须有哪几个槽位

一套能用的检索问答提示词，拆开看就是四块：角色与边界、材料区、问题区、输出约束。缺哪块都可能出问题，最容易漏的是材料区带编号和无依据时怎么回。下面按块说清楚每块写什么。

角色与边界

一句话说明它是什么身份的助手，并明确答案只能来自给定材料，不能引入外部知识

材料区

把检索结果按固定格式排好，每条带编号和来源标识，编号后面要能对上你的原文片段

问题区

用户原话照抄，不要在这里顺手做改写，改写留给单独的步骤处理

输出约束

回答长度、是否分点、无依据时怎么回、引用怎么写，四件事都要写清

写这四块的时候有个顺序建议：先把材料区的格式定下来，因为编号规则决定了输出约束里引用怎么写。材料区如果要编号到片段级别，输出里就能要求句级引用；材料区只是整篇丢进去，那引用就只能到文档名，粒度差很多。

带出处引用的模板怎么写

引用这事，光说「请注明出处」没用，模型会给你编一个看起来像出处的说法。要落地就得把格式钉死：在输出约束里要求每句结论后面跟材料编号，格式统一，比如方括号加数字，跟材料区的编号一一对应。同时补一句「没有出现在材料里的信息不要写」。

1. 定编号规则材料区每条片段前置一个编号，编号直接对应你数据库里的片段 ID，这样输出里的引用能反查回原文
2. 写引用格式在输出约束里明确写出形如「结论[编号]」的要求，并给一个正例和一个反例，模型对反例的敏感度比你想的高
3. 加一条禁写规则补上「材料里没有的内容不要写」，比单纯说「请准确」有用得多
4. 验证引用对不对拿几个答案回去对原文，看引用编号指向的片段是不是真支持那句话，对不上就是材料切分粒度的问题

材料片段本身太长的时候，模型容易引错位置。一个片段里塞了三四个要点，它引了这个编号，但你不知道它指的是哪一句。建议在预处理阶段就把每段切成能独立读懂的小块，编号和块一一对应，别让一个编号对应一大段。

不适用的情况也说一下：如果你的知识库全是表格或代码，直接塞原表模型很难引对，它会看错行列关系。这种先转成文字描述再喂，比如把一行数据写成一句话，引用才稳得住。

答不出来时让它老实说

模型爱硬答，是因为你没给它一个体面的退路。不说清楚答不出来该怎么办，它就默认「必须有回答」。所以要在输出约束里给出固定的兜底句式，比如「根据现有资料无法回答，建议查阅……」，并说明可以补充哪类信息。兜底句要统一，方便你在日志里筛出来。

• 兜底句式写死，不要每次换说法，否则日志里没法按关键词筛
• 别写「尽量回答」「能答就答」这类模糊表述，模型会理解成硬答也可以
• 兜底时可以顺带给一个方向，比如建议补充哪类关键词或换哪个文档，用户体验会好一点
• 定期统计兜底触发率，触发太多说明检索召回有问题，不是提示词的锅

什么情况下这套不适用？面向终端用户的客服场景，直接回「无法回答」体验很差，用户会觉得你这系统啥也不会。这种可以先兜底，再挂一个人工入口或者转接提示，把拒绝变成一次分流。

追问与问题改写这一层

多轮对话里，用户第二句常常很短：「那它多少钱」「这个支持吗」。这种缺主语的短句直接拿去检索，向量召回基本召不到东西，因为库里没有一句话是这么写的。解决办法是加一步轻量改写，把历史轮次里的关键名词补进当前问题，再送去检索。

历史轮次：用户问「某某方案的部署方式」，助手答完后；
用户追问：「它要不要联网」；
改写后送入检索：「某某方案 是否需要联网」；
改写只补主语和指代，不改原意，不同义扩写。

有个要点：不要让同一个模型在同一次调用里既改写又回答。两件事混在一起，模型会顺着自己的改写直接答，检索这一步就白做了。拆成两次调用，改写归改写，回答归回答，中间留出检索的位置。

改写模板只做一件事：补主语、补指代、补单位。不做同义扩写，扩写会把原意带偏，用户问的是这个方案的联网要求，你扩写成网络配置最佳实践，召回的东西就跑偏了。如果你的检索接口本身就支持多轮上下文，这层可以先跳过，先看召回效果再决定要不要加。

材料塞不下时怎么取舍

检索返回的片段数量不是越多越好。塞太多，模型抓不住重点，真正相关的那条被淹在一堆边角料里，还白白吃掉上下文预算。这里没有万能条数，得看你问的问题类型和你文档的颗粒度，可以到 基础概念词典：Token、上下文、温度（/ai-dict/category/basics） 把上下文长度的口径弄清楚，再对照你实际检索结果的长度做取舍。

截断这件事最好留个记录。日志里记下这次送了几条、截在哪一条、被丢掉的是哪些，出错的时候你能很快判断是检索召回了没用的东西，还是答案就在被截掉的那部分里。不同检索方案的召回行为差别不小，站内对比页有整理：工具与检索方案对比（/tools/speed-test），选之前可以先看一眼。

怎么判断这套模板在你库里管用

模板好不好用，凭感觉看不出来，得有一小批带标准答案的问题去跑。问题不用多，但覆盖面要对：材料里明确写了的、材料里根本没提的、需要跨两段拼起来才能答的，三类都要有。

1. 准备测试问题集每类问题准备几条，标准答案写清楚出自哪个片段，别只写一个结论
2. 跑一遍看三个指标答对没有、引用编号对不对、该拒答的时候有没有拒，三个分开记
3. 换写法对照同一个问题换两种模板写法各跑一遍，差在哪个槽位就能看出来
4. 一次只改一块改角色就只改角色，改引用格式就只改引用格式，不然你说不清是哪个改动起的作用

零散调整很难看出效果，一次改一个变量是最省时间的做法。如果跑下来发现「材料里没有的」那类问题总是被硬答，那就是兜底句式没写死；如果引用总是对不上，那就是材料切分粒度的问题，跟模板文案没关系。想横向看看别人踩过哪些坑，可以去 指南中心（/guides） 找相关主题。

什么情况下别硬套模板

模板是好东西，但不是所有场景都该上。硬套会带来一堆没必要的约束，反而把简单问题搞复杂。下面几类场景建议绕开。

• 纯闲聊或开放讨论：不需要引用约束，加了会让回答变得僵硬，用户能感觉出来
• 材料本身质量差、互相矛盾：模板救不了，先回去整理知识库，把冲突内容合并或下架
• 单轮、单文档、答案唯一的小场景：写长模板收益很低，一句「根据以下内容回答」就够了
• 检索还没调通的阶段：召回都不准，先别急着优化提示词，顺序反了会白费功夫

判断标准其实很简单：如果你的场景里「答案必须有出处」是硬需求，模板值得写；如果只是随便查查、对话式探索，模板反而添乱。这条线画清楚，能省下不少调优时间。

提示词不是越详细越好，是把该约束的地方约束死，剩下的留空。