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

这问题太真实了，光靠prompt硬约束肯定不行。我试过把知识库直接塞进system message，但token一长模型照样懵。建议你搞个简单的意图分类前置，先判断是查库存还是问政策，库存这种实时数据直接走API查，别让模型生成，政策类再让它基于文档总结。另外回复里加个置信度提示，比如“根据当前信息”这种词，能少挨不少骂。

试试把知识库切片塞system里做检索兜底，再给模型一个“不知道就说不知道”的固定话术，准确率能上来不少。

把知识库切成小块，让模型先检索再回答，比硬塞prompt稳得多，还能减少编造。

知识库肯定得塞，但别一股脑全扔进去，按商品类目分块检索再拼进prompt，准确率能上去不少。system message做角色设定确实稳，配合few-shot给几个标准问答示例，比单纯强调“别乱说”管用。

system message做角色限定确实比user prompt稳，但核心还得靠知识库兜底。你这种库存和政策类问题，建议把商品数据直接塞进context里，让模型只做检索+改写，别让它自己发挥。另外可以试试few-shot，给几个“不确定就明说”的例子，比单纯加一句“别瞎编”管用。不过GPT-3.5对长上下文理解容易飘，记得把关键信息放最后。

系统消息做角色限定确实比塞user prompt稳，但关键还得配合外部知识库做检索增强，把商品库存这些动态数据实时查出来拼进prompt里，模型就不会瞎编了。另外可以给模型一个“不知道就明确说不知道”的指令，再给它几个固定的政策模板让它套用，比让它自由发挥靠谱得多。你试过用few-shot例子给它几个对话样本吗，那个对稳定输出格式很有帮助。

我之前也踩过这坑，光靠prompt约束很容易翻车。后来是把商品库和退货政策转成向量塞进上下文，让模型先检索再回答，比硬记靠谱得多。system message做角色设定确实更稳，但记得加个“不确定就触发转人工”的兜底逻辑，不然它还是会硬答。另外可以把“已知信息”和“未知信息”分开写在例子里，few-shot比单纯命令有用。

这题我熟，之前做类似项目踩过坑。你光靠prompt硬扛不如把知识库拆成小片段，用embedding检索后再拼进system message，让它基于检索结果回答，比纯靠模型记忆靠谱多了。

另外角色设定里最好明确写“你是客服，只能根据提供的资料回复，资料里没有就明确说不知道”，比“只回答确切知道的”这种模糊指令有效。

还有个小技巧，把常见问题的标准答复写进few-shot示例，格式固定下来，模型跟着格式走，胡编的概率会低很多。

最后，库存这种实时数据别指望模型自己判断，接口直接查数据库，把结果动态塞进prompt里它才敢说准话。

知识库塞进system message里是必须的，再配合few-shot示例限定回答边界，比单纯堆prompt稳得多。

知识库必须塞，但得带来源标识让模型只认库里数据，再配合system message锁死角色边界。

system message确实更稳，把政策细节写成if-then规则，比单纯靠prompt约束靠谱多了。

建议把知识库检索结果直接拼到system message里，再限定只答库内内容，比单纯调prompt稳得多。

我们之前也踩过这坑，后来加了RAG流程，模型乱编概率明显降了。

说实话你这个情况太典型了，我一开始用GPT-3.5做客服demo也栽在这上面。光靠prompt让它“别乱说”基本是堵不住的，模型本质是在做概率生成，不是查数据库，你越强调“只知道这些”，它反而越容易陷入那种防御性的“我不清楚”。我后来是干脆把知识库拆成结构化条目，比如“商品ID-库存状态-政策原文”，然后塞进system message里，让它先定位再回答，这样准确率明显上去。角色设定确实比user prompt稳，因为system message是全局指令，能约束整个对话的基调，但你不能只写“你是客服”，得给它具体的行动规则，比如“当问题在知识库中找不到时，必须说需要人工转接，并给出客服联系方式”。另外我觉得你可以试试few-shot，在prompt里给几个“用户问-正确答”的例子，尤其是那种库存不足的边界情况，模型会模仿这个格式，比单纯加限制条件有效得多。还有个小技巧，把“不确定”也设计成一种业务话术，比如“这个商品我这边暂时查不到实时库存，您稍等我看下”然后接个转人工，这样既不会瞎编，又不会显得太生硬。说到底，大模型做客服不能指望它“记住”什么，要把它当成一个会理解意图的接口，真正的数据校验还得靠代码去查库，prompt只是负责把查到的结果表达得自然点。

我之前踩过类似的坑，后来把知识库和检索拆出来了，不直接塞prompt，而是先用向量检索把相关条目拉出来，再让模型基于这段上下文回答，准确率高很多。system message做角色设定确实比user prompt稳，我会在system里明确“你是客服，只能依据提供的资料回答，资料里没有就明确说不知道”，这样它就不会硬编了。另外你试试把“不确定”也当成一个正式选项，告诉它“如果信息不全，必须说需要核实”，比单纯说“别乱编”有效得多。

说实话你这个场景我踩过差不多的坑，纯靠prompt约束事实性内容基本是死路，模型该编还是编。建议把库存和政策这类动态数据做成API或数据库查询，prompt里只让模型根据返回结果做格式化输出，别让它当知识库用。systeam message做角色设定确实比user prompt稳定，但核心还是把“能查的”和“能编的”明确切分开，比如给模型一个固定话术模板，没查到就回“正在核实”，这样比“我不清楚”自然得多。另外可以试试few-shot，给几个“有货/无货”的问答示例，模型会学得更像样。

说实话你这个场景我踩过一样的坑，光靠system message定角色确实不够，库存这种动态数据必须走函数调用或检索，让模型在回答前先查接口拿结果，而不是靠它记忆。政策类内容可以做成FAQ向量库塞进context，但要注意控制token长度，不然成本涨得飞快。另外你可以试试在prompt里给模型一个“不知道就说不知道”的兜底话术模板，比单纯说“只回答确切知道的”要自然得多，至少不会直接把对话聊死。

我之前也踩过这个坑，光靠prompt压模型不现实，它天生就爱编。后来我把库存和退货政策直接结构化塞进system message里，比如用JSON格式给个“当前已知事实”字段，然后明确告诉它只能引用这里的数据，超出范围就回“需要人工确认”，这样比单纯说“只说你知道的”管用多了。

另外角色设定确实比user prompt稳，但别只给“你是客服”这种空泛设定，得把决策树写进去，比如“查不到库存就引导转人工”，这样它就知道该闭嘴还是该继续聊。你试过给模型喂一个简单的API查询工具吗？让它先调接口再回答，可能比全塞知识库更省token，也不会因为信息过期乱说。

知识库必须塞，但得切成小段让模型检索后再答，不然它分不清事实和编造。

system message定角色挺稳的，但关键得给它一个“不知道就说不知道”的兜底话术，别让回答卡死。

知识库必须塞，最好走RAG，另外system message里把“库存未知就明说”写死，比单纯靠prompt靠谱多了。

我做过类似的客服demo，你这个问题太典型了。核心不在于单纯堆prompt，而是把“知识库”和“生成”分离。我的做法是：先用一个检索步骤把相关商品和政策片段抽出来，再塞进system message里让模型基于这些片段回答，而不是让它从记忆里瞎猜。你试过的那种“只回答确切知道的信息”其实是个陷阱，因为模型没法区分“确切的数据库记录”和“它训练数据里的常识”，所以一紧张就全说不知道。另外，system message确实比user prompt稳，因为你可以放固定的角色和规则，比如“你是客服，只能引用以下文档，若文档无答案则说需要转人工”，这样user那边只输入用户问题，不会互相污染。还有一个细节：对于库存这种实时数据，建议用function calling去查API，而不是让模型判断有没有货，哪怕你知识库里塞了“当前有货”，下一秒也可能卖完。最后，退换货政策这种相对静态的，倒是可以完整写进system里，但注意控制长度，太长模型会忽略中间部分，我一般只放摘要+链接，需要细节时再触发检索。

说实话system message做角色设定确实比user prompt稳，但光靠这个也拦不住幻觉。我建议你把知识库拆成结构化条目塞进上下文，比如用“当前库存：SKU123=0”这种硬数据，模型就没法自由发挥了。另外给个兜底话术模板，比如“具体库存以结算页为准”，比让它硬答靠谱。还有，温度调低点，0.2以下，能少编很多。