用大模型做客服，prompt怎么写好才能不“胡说八道”？

system message里把知识库关键字段写成硬性规则，再加个“不确定就反问用户”的兜底指令，实测比单纯禁编靠谱。

你这情况太真实了，光靠prompt硬控确实容易翻车，我试过把知识库转成向量塞进上下文里做few-shot，模型参考具体条目后瞎编的概率明显低了。system message里加一句“仅基于以下知识库内容回答”配合角色设定挺稳的，但记得定期更新知识库，不然过时政策它也会照搬。另外可以把退换货这类高频问题写成Q&A模板放在prompt开头，让它先匹配再回答，准确率会高不少。

说实话你这个情况太典型了，我之前做客服bot也踩过同样的坑。我的经验是system message里得把角色设定和边界规则写死，比如“你只根据以下知识库内容回答，超出范围请引导用户转人工”，然后配合few-shot示例把“有货”“无货”的回复模板各给一两轮，模型就不太容易放飞了。知识库肯定要塞，但建议用检索增强的方式动态注入，别一股脑全扔进prompt里，不然token一长它反而容易犯迷糊。另外可以试试在每次用户输入时，把当前对话历史里关于库存的关键信息显式高亮一下，模型会更老实。

我之前踩过类似的坑，核心问题其实是模型分不清“事实性信息”和“推理空间”。单纯靠prompt约束它“别乱编”效果有限，因为LLM天生倾向于补全对话而不是承认不知道。我的做法是把知识库拆成结构化数据，在system message里明确告诉它：“库存信息只认数据库返回结果，政策内容只读固定文档，超出这些范围就引导用户找人工客服”。这样它就不会自己瞎编数字了。

另外user prompt里别让它做“判断”，而是做“匹配”。比如你问“这个商品有货吗”，模型容易自由发挥。改成“请根据以下库存列表回答：商品A库存5件，商品B库存0件…顾客问商品B，你该说什么？”它会老实地引用数据。建议把系统角色设定为“信息中转站”而不是“客服专家”，准确性会稳很多。你那个demo如果API能接入实时库存查询，其实比塞prompt更可靠。

这个问题我太有共鸣了，之前做金融客服demo也踩过类似的坑。我的经验是system message里明确角色加严格规则确实比user prompt稳，比如“你是电商客服，只回答以下知识库内容，不在知识库的选项一律说‘请转人工’”。另外知识库塞进去是必须的，但别直接全量丢，用检索把最相关的几条上下文拼到prompt里，准确率能明显提升。还有个细节是给模型一个“沉默”选项，比如不知道就回复“我需要查证一下”，比硬说“不知道”更符合客服场景。

同感，单纯靠prompt限制模型不胡说其实挺难的，特别是库存这种实时数据。建议你试试把知识库直接塞到system message里，用一个固定的结构比如“当前库存信息：[商品名]：有货/无货；退换货政策：7天无理由...”然后让模型只基于这个内容回答。这样它就不会自己编了，而且还能结合上下文。另外我自己的经验是，user prompt里加一句“如果以上信息中没有答案，请直接说无法确认”会比单纯说“只回答确切知道的”更稳当。

把知识库塞进system message里，再配合few-shot示例，实测能压住不少胡说八道的问题。

这问题太真实了，我之前做售后bot也踩过坑。一个比较稳的做法是把知识库拆成结构化文档，用system message明确角色和边界，比如“你只基于下面这份退换货规则回答”，然后把规则分段塞进上下文。另外给模型加个“不确定就引导用户转人工”的兜底指令，比硬让它猜靠谱得多。你可以试试把库存这类动态数据单独用API查询后拼接进prompt，别全靠模型记忆。

我也踩过这个坑，单纯靠prompt约束确实容易翻车。建议把知识库直接结构化塞进system message里，比如商品库存、退换货规则写成json或表格格式，再明确告诉模型“数据优先”。另外实测加个“如果知识库没有对应信息，请直接告知用户暂无法确认”这种兜底指令，比单纯说“不知道”靠谱多了。

实测把知识库拆成小块塞system里，配合few-shot示例效果比单改prompt稳定很多。

这个我深有体会，光靠prompt约束真不行，尤其库存这种动态数据，模型根本没法实时知道。建议你把知识库拆成结构化片段，用system message固定角色，再在user prompt里加一个“优先参考以下信息”的指令，每次把当前库存和政策直接塞进去。另外可以加个兜底逻辑，比如“如果信息不在参考中，请引导用户联系人工”，这样既不会乱编也不会直接拒答。

这个问题我踩过类似的坑，单纯靠prompt限制其实不太够，尤其库存这种动态数据。建议把知识库做成检索增强的方式，比如把商品库存、政策文档向量化存起来，每次提问先检索相关片段再拼进prompt，准确率高很多。另外system message里给角色一个明确的“知识边界”设定，比如“你只能根据提供的资料回答，资料里没有就说需要核实”，比直接说“不知道”要自然。可以试试把“不知道”改成引导用户转人工或查询，产品那边更容易接受。

说实话你这个情况太典型了，我当初做售后bot也踩过一模一样的坑。纯靠prompt约束“不要编造”基本是玄学，模型对“知道”和“不知道”的边界感其实很模糊，尤其当知识库没接入的时候，它会把训练数据里的常识和你的商品信息混在一起。我的做法是强制把知识库做成结构化片段塞进system message，比如用JSON格式把每个商品的库存状态、退换货时限、特殊条款都列清楚，然后在user prompt里只留一个“请基于以下资料回答”的指令，这样模型会倾向于引用原文而非自由发挥。另外你可以试试在system里加一条类似“如果用户问题不在资料中，必须回复‘该问题需要人工核实’”的硬规则，但别用“我不清楚”这种模糊表述，否则它连能答的也给你拒了。还有个细节：把对话历史里的用户问题和你自己的回复拼接成few-shot示例，放两三条典型场景进去，比单纯堆叠规则有效得多。不过说实话，GPT-3.5对复杂多轮上下文还是容易漂，我后来换成了带function calling的版本，让模型先调一个查询库存的接口再回复，准确率才真正稳住。你可以先试试把知识库拆成小块动态嵌入prompt，别一次性全塞进去。

这题我太有感触了，之前做类似项目时也踩过这坑。单纯在prompt里写“别乱说”根本没约束力，模型该幻觉还是幻觉。我的经验是别把知识库塞进system message里，而是把商品信息做成结构化上下文动态拼进user消息，比如每次调用前从数据库拉出当前商品库存状态，直接写成“商品ID 12345库存为0，退货政策是七天无理由”，这样模型基于事实回答，胡说八道的概率会小很多。另外角色设定确实放system里更稳，但重点是给它定义一套“不确认就请求澄清”的回复模板，比如“关于库存我需要查询后确认”，而不是让它自由发挥说“我不清楚”。你还可以试试few-shot，给两个标准问答对，一个是有具体数据时怎么答，一个是没数据时怎么引导用户转人工，效果比纯指令强不少。还有个细节，把“退换货政策”这种静态内容单独抽出来做成固定函数调用，别依赖模型记忆，这样既准确又省token。最后建议调低temperature到0.2以下，尤其在客服场景，宁可保守也别让它发散。

把知识库拆成小块塞进system message，再让模型先检索后回答，比光靠prompt硬控靠谱多了。

知识库必须塞，不塞它只能靠编，system message定死边界比user prompt好使。

知识库必须塞，但别全塞，用RAG检索top-k再拼进system message，准确率能上来。

说实话我试过类似场景，光是改prompt真不够，建议直接上RAG，把库存和政策做成向量库检索，让模型先查再答，比硬记靠谱得多。system message做角色设定确实更稳，但关键还是要给模型一个“拒绝编造”的出口，比如明确教它说“这个我需要查一下”，配合函数调用去查实时数据。另外你那个“只回答确切知道”太绝对了，改成“不知道的就引导用户转人工”会自然很多。

系统消息里把知识库接口的结果直接拼进prompt，再让它只基于这段内容回答，比靠角色设定稳得多。

system message里把知识库按问答对固化，再限定只输出库里匹配的结论，比靠prompt硬约束靠谱。