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

我之前也踩过这坑，光靠prompt限制确实不靠谱。后来是把知识库直接塞进system message里，再配合检索接口把相关商品信息动态拼进去，模型就只能基于给定数据回答了。另外角色设定还是得放system里，user prompt留给用户问题，这样上下文更稳定。你可以试试让模型先复述一遍知识库里的关键条款，再回答，能减少瞎编概率。

这问题太真实了，我试过把知识库拆成问答对塞进system prompt里，模型明显稳很多，但注意别一股脑全塞，超长反而会分散注意力。另外建议给模型一个“不知道”的兜底话术模板，比如“库存信息以页面显示为准”，比让它自由发挥强。你用的是函数调用还是纯文本检索？如果是电商场景，实时库存最好还是走API查完再拼进prompt，别让模型自己判断。

system message做角色限定确实比user prompt稳，但核心还是得把知识库“结构化”喂进去，比如把商品信息转成json格式放上下文里，再让模型只做提取和判断。另外可以加个“不知道就说不确定，然后引导转人工”的兜底逻辑，比单纯说“只答知道的”好用。

说实话你这个情况太典型了，光靠prompt约束不解决问题，核心是把知识库外挂进去，让模型只做检索后的归纳，别让它凭记忆生成。system message里明确角色和边界确实比user prompt稳，但得配合函数调用或者RAG，把库存和政策这些动态数据拉出来塞进上下文，它才不会瞎编。另外可以试试让它在不确定时反问而不是直接说“不清楚”，比如“这个商品您需要确认下具体型号，库存我帮你查”，这样既像真人又避免硬伤。

我之前做类似项目也踩过这个坑，光靠prompt约束真的不够，GPT-3.5对“不知道”和“没有”的边界理解很模糊，你越强调“只回答确切知道”，它反而越倾向于用模板化的话术糊弄你。我的做法是把知识库直接切块塞进system message里，比如库存状态、退货政策各编成结构化条目，然后明确告诉模型“只能引用以下内容回答，超出范围就回复转人工”。这样比单纯在user prompt里加限制稳得多，因为system message的优先级更高，而且模型不容易被用户绕晕。另外，你还可以加一个“置信度”机制，比如让它在回答前先判断问题是否在给定资料里，如果匹配度低于某个阈值就主动反问确认，而不是硬答。不过说实话，电商这种高频变动信息，靠prompt根治很难，最好还是配合一个简单的检索接口，让模型先查库再组织语言，不然就算prompt写得再好，库存一变它还是会出错。你目前是用纯文本还是接API做实时查询？

知识库必须得塞，不然它压根分不清哪些是知道的哪些是编的，再调system message固定话术就行。

把库存和退货政策做成检索式提示词，别让它自由发挥，我家就是这么干的，准确率立马上去。

说实话你这个场景我踩过一样的坑，光靠prompt约束“别乱编”基本没用，模型分不清“不知道”和“没查到”。我后来是把商品库和售后政策转成JSON格式塞进system里，再用few-shot给几个“库存不足时”的回复样例，准确率立刻上来了。另外你试试把“只回答知道的信息”改成“如果知识库没覆盖，就引导用户转人工”，比让它闭嘴强多了。

系统提示词里把知识库做成json格式塞进去，让模型只从里面检索匹配，匹配不到就明确说不知道。另外把库存和政策分开成两个独立任务，别让它在一条回复里自己判断，会好很多。

这问题我踩过坑，光靠prompt硬扛真不行，知识库必须得塞，但别全文丢进去，把商品信息按SKU拆成结构化片段，用检索把相关几条拼进system message里。另外角色设定确实比user prompt稳，但得明确写“如果你没有在提供的数据中找到答案，直接说需要转人工”，不然它还是容易自己脑补。还有个小技巧，库存和退换货政策分开做两个独立指令块，别混在一个prompt里，模型切上下文容易乱。

system里把知识库按json格式塞进去，再限定只能查库回答，比靠prompt硬憋靠谱多了。

我们之前也踩过这个坑，光靠prompt约束模型不现实。现在我们是把商品库存、退货政策这类动态数据提前查好，拼进system message里，并且明确标注“以下信息来自内部数据库，回答时只能引用这些内容”。另外给模型加两三个few-shot示例，比如“如果用户问库存，而数据库里没有，就回答‘需要帮您核实’”，这样比单纯说“不知道”自然多了。你可以试试把知识库塞进去，但记得限定回答范围，不然它还是会自己脑补。

我最近也踩过类似的坑，关键其实不是堆prompt，而是把知识库直接注入到system message里，让模型只在给定的上下文里做筛选，再加一条“如果信息不在资料中，就明确说无法确认”的兜底规则。另外库存这种动态数据别让模型猜，要么接API实时查，要么让它反问用户“您要哪个型号我帮您确认”，比硬编答案靠谱多了。

说实话你这个场景我踩过坑，光靠prompt约束不靠谱，模型该编还是编。建议把商品库存这种强实时数据做成接口，用function calling去查库，让模型只负责把结果转成自然语言，别让它记事实。政策类的内容可以塞system message里做个角色设定，但得配合few-shot示例，不然它容易一上来就甩“不清楚”。另外可以试试在user prompt里明确给个“不知道就引导转人工”的兜底话术，比让它硬答强多了。

说实话system message确实比user prompt稳，但光靠角色设定解决不了“编库存”这种事实性问题。我建议你把商品信息和政策拆成结构化的json塞进system里，然后加一条硬规则：凡是不在json里的数据一律回答“需要人工确认”。另外可以试试few-shot，给几个“有货/无货/政策模糊”的对话范例，模型会更容易学会边界感。

不过你提到“只回答确切知道的”会导致过度拒答，我也踩过这个坑——关键是要在prompt里区分“知识库内的精确信息”和“通用常识”，比如退换货政策如果写明了就回答，没写就引导用户转人工，别让它自己发挥。还有个土办法，就是每次查询前先调一次库存接口，把结果动态拼进user prompt里，模型就没机会瞎编了。

知识库必须塞，但得让模型先检索再回答，不然它真敢给你编个库存出来。

这问题我太有同感了，之前做个售后问答demo也是被“一本正经地胡说八道”搞到头秃。你光靠system message写“只回答确切知道的”其实没用，大模型分不清“知道”和“推测”的边界，它觉得库存逻辑上该有货就编了。我的经验是必须把“知识库”拆成结构化数据直接塞进prompt里，比如用JSON格式把商品ID、库存状态、政策条款列清楚，然后明确告诉它“只能从这个列表里取答案，查不到就回复具体话术比如‘库存更新中，请稍后’”。另外，system message做角色设定确实比user prompt稳，但得配合few-shot，给两个“问题-正确回答-拒绝回答”的示例，它才能学会区分“可答”和“不可答”。还有一个坑是上下文太长会导致注意力漂移，建议把知识库放最前面，用户问题放最后，中间用分隔符隔开。最后，如果预算允许，试试用GPT-4或者带function calling的接口，让它先查数据库再生成回复，准确率能上一个档次，但成本也得算进去。

把知识库拆成小块检索后塞进system message，再让模型只基于检索结果回答，能少很多瞎编。

把知识库检索到的内容塞进system message里，同时限定只答库内信息，比单纯靠prompt硬压靠谱得多。

我之前也踩过这个坑，后来发现光靠prompt约束不靠谱，得把知识库和提示词分开处理。我是把商品信息、政策这些结构化数据先检索出来，再拼到system message里让模型只基于这段上下文回答，效果比单纯堆prompt稳很多。另外你那个“只回答确切知道”的说法太绝对了，改成“根据提供的资料回答，资料中没有的请说明需要转人工”会好点，模型至少不会直接摆烂。还有一个细节，多轮对话里记得把用户历史问题和检索结果一起喂进去，不然它容易跑偏。

这问题太真实了，我试过让客服模型只答知识库里的东西，结果它把“不确定”当成万能答案，连“今天天气不错”都能给你回个“请咨询人工”。后来我把system message写成“你是客服，只能引用我们提供的商品数据，没有就引导用户问人工”，再把库存表直接塞进user prompt里，效果比让它自己推断强多了。不过你那个“只回答确切知道”的写法确实容易矫枉过正，建议给它几个明确的兜底话术模板，比如“库存我这边查不到，帮您转人工”这种，比让它自由发挥可控。