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

建议把知识库检索结果拼进system message，再让模型只基于检索内容作答，比单纯靠prompt约束靠谱得多。

说实话我之前也踩过这坑，光靠prompt约束真的不行，尤其库存这种动态数据，模型根本没法判断。我是直接把知识库里的商品信息和政策文档做成检索，把检索结果塞进system message里，再让模型只基于这些内容回答，效果稳很多。

另外角色设定放system message确实比user prompt管用，但关键是要加一句“如果信息不在给定资料里，直接说需要人工核实”，别让它自由发挥。你还可以试试few-shot，给几个“没货但委婉拒绝”的例子，比单纯下指令靠谱。

说实话这个问题太典型了，我之前做类似项目也踩过坑。光靠prompt限制“别瞎说”真没用，模型根本分不清哪些是可信数据。我现在是把知识库拆成结构化片段，比如库存和退换货规则单独存成JSON，然后让system message告诉它“只能引用以下数据回答”，效果比单纯堆约束好很多。

另外你提到“不清楚”的问题，我试过在prompt里加一个兜底指令：如果知识库里没有，就反问用户“您具体想查哪个商品的库存呢”，把话题引回流程里，比硬说不知道自然多了。你那个政策解释的case，可以试试把常见问题做成固定话术模板，让模型先匹配模板再回答。

不过说实话，GPT-3.5的上下文理解还是有限，如果产品要求高，建议直接调函数调用或者微调个专用模型，不然总会有漏网之鱼。你现在是纯文本交互，还是已经接上数据库实时查询了？

知识库必须塞，但得让模型先检索再回答，不然它只会一本正经编数据。

system message做角色限定确实比user prompt稳，但关键还是得给模型一个“知识边界”的钩子。比如把库存和退换货规则写成结构化QA对塞进system，让它只基于这段内容回答，超出就明说不知道。另外可以加个强制动作，比如“若无法确认则回复：请转人工”，比单纯说“别乱编”有效得多。

我之前踩过坑，发现光靠prompt约束不够，得配合后处理逻辑。比如把商品库接个API查询，模型只负责把问题转成查询参数，拿到结果再生成话术，这样彻底断掉它瞎猜的路径。你试试看，准确率能上来一大截。

对了，你那个demo用GPT-3.5的话，温度参数调到0.2以下没？高温值很容易让它在不确定时自由发挥，低温配合few-shot示例，比反复强调“要准确”管用。政策类问题直接给几个标准问答模板，它就会照着那个格式走，不太会跑偏。

说实话你这个场景我太熟了，之前做金融客服demo也踩过同样的坑。单靠prompt约束“别乱说”基本是死路，因为模型自己根本分不清“知道”和“不知道”的边界，你越强调它越容易缩回去装死。我的经验是核心得把知识库做成显式的检索步骤，而不是硬塞进system message里——比如先把商品库存和退换货政策按条目拆成结构化数据，在prompt里让模型先判断用户问题是否命中知识库条目，命中就引用原文，没命中就直接说“需要转人工”。另外system message做角色设定确实比user prompt稳，但重点不是“你是客服”，而是明确告诉它“你只能使用以下提供的文档回答，禁止推测”，同时给几个few-shot例子，展示哪些情况要查库、哪些情况要拒绝回答。还有个野路子是加一层“置信度开关”，让模型输出答案时附带一个0到1的自评分，低于某个阈值就自动触发兜底话术，这样既不会瞎编也不会完全不答。你可以试试把政策部分单独做成问答对，库存部分用实时API查询结果拼进prompt，这样模型只是做格式化输出，而不是靠记忆生成。

我个人觉得system message做角色设定确实比user prompt稳，但核心还是得把知识库结构化塞进去，比如把库存和政策拆成json或faq列表让模型检索，而不是让它凭记忆生成。另外可以试试让模型先输出“根据数据库记录”再回答，或者加个置信度门槛，低于某个值就转人工。不过GPT-3.5对这类任务的指令遵循能力有限，有条件的话换4或者用微调会省心很多。

知识库得切片塞进system里，再让模型只依据检索结果回答，能压住不少幻觉。

这问题太真实了，我试过把库存和政策直接拼进system prompt，效果比塞user prompt稳很多，模型会默认这些是硬约束。但关键是得把知识库拆成“事实块”加时间戳，比如“截至今天10点库存X”，不然它还是会拿旧数据瞎编。另外你可以加个兜底指令，让它在不确定时反问“需要帮您核实吗”而不是直接说不知道，这样既保准确又不显得呆。对了，你试过用few-shot给几个边界案例吗？我觉得比单纯堆规则管用。

说实话system message确实比user prompt稳一些，但光靠这个不解决根本问题。我们之前踩过坑，最后是把商品库和退货政策单独做成检索接口，让模型只负责从返回结果里做摘要，不直接生成事实性内容。你试试把“不知道”改成“我帮你查一下”加上一个触发调库的动作，这样就不会瞎编了。另外上下文这块，建议把最近几轮用户问题里的关键实体抽出来塞进prompt，比全量对话扔进去效果好很多。

这问题太真实了，我当初做类似demo的时候也被“幻觉”折磨得够呛。你光靠prompt约束“不许编”基本没用，模型该自信还是自信，你得给它一个“可检索的锚点”。

我的做法是，把知识库（比如库存表、退换货规则）直接拆成结构化片段，通过system message注入，然后明确告诉它“只能依据以下文档回答，无法确认就转人工”。重点不是让它“不胡说”，而是让它“无据可依时主动认怂”。你可以试试在system里加个“若信息不在文档中，回复‘该问题需专员核实’”，比单纯说“不知道”要自然很多。

另外角色设定确实比user prompt稳，但别只给身份，得给“行为准则”和“边界条件”。比如“你是客服，拥有实时库存接口权限”，但实际没接API，这个权限就是假的，它还是会编。更靠谱的是把“数据源”写进system，再配合few-shot，给两三个“有货/无货/政策模糊”的正反例，它基本能学会“不越界”。

还有个小坑，别把所有内容都塞进一条prompt，上下文太长反而会稀释注意力。建议把政策类固定话术放system，库存这种动态信息通过user消息按轮次更新。你要是能接受延迟，可以试试先用模型做意图识别和槽位提取，再拿结果去查API，最后把查询结果拼进prompt让它生成回复，这样基本能杜绝编造。就是工程量大点，但demo阶段值得折腾。

其实关键在把知识库做成函数调用，让模型只负责抽取参数，库存这种动态数据别让它自己答。

这问题我踩过坑，单靠prompt约束不如直接把知识库做成检索增强，把库存和政策拆成结构化条目塞进system message里，让模型只做信息匹配和话术转换，比让它记硬规则靠谱得多。另外你试过给模型加个“不确定就反问”的兜底逻辑吗？比如让它引导用户去查订单号或商品ID，比硬说不知道体验好很多。

说实话你这个痛点太典型了，光靠prompt压是压不住的。我建议把知识库做成检索增强的接口，让模型先查后答，而不是让它背知识。system message里把角色限定为“只根据以下资料回答”，同时给个明确的“未找到答案时请转人工”的兜底指令，比单纯让它闭嘴好使。另外库存这种实时数据，别指望模型自己判断，宁可多写几行代码从数据库拉状态拼进prompt，也别让它猜。

说实话system message做角色设定确实比user prompt稳，但核心还是得给模型一个“事实边界”。我试过把库存和退换货政策整理成结构化文本塞进system里，同时明确写“只基于以下信息回答，不确定就说需要人工确认”，比单纯说“别乱编”管用得多。另外可以加个前置判断逻辑，比如让模型先抽取用户问题里的商品ID和意图，再决定是调知识库还是走兜底话术，这样能减少那种“一本正经瞎说”的情况。

我之前踩过类似的坑，单纯在prompt里强调“别瞎编”基本没用，模型分不清“不知道”和“拒绝回答”的边界。后来我把知识库拆成两块，一块是商品SKU的实时库存表，一块是政策文档，通过system message告诉它“你只能基于以下json数据回答，数据里没有的就说需要人工确认”，同时给每个商品ID配上明确的库存字段。这么做以后，它至少不会自己推断“应该有货”了，但有个新问题——如果用户问“这个手机壳配不配iPhone 15”，知识库里没有这个关联，它还是会硬编，所以后来我又加了一层意图识别，先判断问题是不是“事实型”，如果是，就直接从库里查，查不到就走话术模板。另外我发现把退换货政策写成if-then的规则放进去比让模型自己理解更稳，比如“如果超过7天且未拆封，则支持退货”，这样它回答“可以退”之前会先匹配条件。你现在这个demo，建议先别急着全塞给模型，试试把库存查询做成独立的function call，让模型只负责把用户问题转成参数，查询结果再回填给模型组织语言，这样准确率会高很多。

这问题太真实了，光靠prompt硬约束肯定不行，模型该编还是编。我建议把商品信息做成结构化上下文塞进system message里，比如库存状态、政策条款都按固定格式写清楚，再让模型只基于这段内容作答。另外user prompt里加个“如果用户问的信息不在上方列表，就回复需要转人工”的兜底逻辑，比单纯说“不知道”强得多。

说实话这问题太典型了，光靠prompt压幻觉基本压不住，我们之前试过把知识库直接塞进system message，token一长反而更容易乱。建议你改成两步走：先用API做个检索，把库存和政策的准确信息抽出来拼进user prompt，再让模型只基于这段给定的上下文生成，别让它自己回忆。另外角色设定放system里确实比user稳，但关键得加一句“如果上下文里没提到，就明确说不知道，不要推测”，比“只回答确切知道”那种空泛的指令好用得多。

system message确实比user prompt稳，但光靠角色设定也治标不治本。我建议把知识库抽成独立的检索步骤，先让模型根据用户问题判断要不要查库，再决定回答，这样能减少瞎编概率。另外你可以试试在prompt里加一个“置信度门控”，让模型对不确定的信息直接说“需要核实”，而不是硬答。

你这问题其实踩中了好多人的坑，我刚开始搞客服bot的时候也这样。光靠prompt约束模型不乱编，基本是治标不治本，因为GPT-3.5的知识截止和幻觉问题摆在那，你让它“只答知道的”，它反而会缩成一团。我后来是把知识库跟检索分开做，比如把商品库存、退换货政策这些结构化数据存成JSON，用函数调用的方式让模型先查再答，而不是让它从记忆里瞎猜。system message确实比user prompt稳，但前提是里面写清楚“你是客服，只能基于工具返回的信息回答”，再加一条“如果工具没返回，就明确说需要人工”。你那个“不解释政策”的问题，很可能是你把约束写得太死，模型把“不编造”理解成了“少说话”，可以试试给它几个具体的回答模板，比如“根据系统记录，该商品缺货，建议您看看替代品”，这样它既有依据又有话术。另外，上下文管理也很关键，别让模型把用户多次提问混在一起，每轮对话前清空或只保留当前session的关键信息，不然它容易串。最后，建议你加一层答案校验，比如让模型输出引用来源ID，后台比对一下，不匹配就拦截，这招比调prompt省心多了。