如何为对话式 AI 系统设计提示词
- 发布时间
- 最近更新
如今，LLM 已成为对话式 AI 系统的核心。具体来说，LLM 让 对话式 AI——最初基于庞杂的电话菜单构建——具备动态功能，并提供更接近人类的体验。不过，LLM 并非一劳永逸的升级方案；默认情况下，它们并未针对人类口语微调，因此需要专门设计提示词。
开发者为对话式 AI 编写 LLM 提示词时，常犯的错误是沿用培训人工员工的那套方法。这种策略看似直接，却很少奏效。LLM 的假设不同于普通人，其默认语气和范围也不适合口头互动。
接下来，我们将介绍如何通过提示词引导 LLM，构建成功的对话式 AI 系统。还可以在 ElevenLabs 开发者文档中阅读更全面、更技术性的指南。
旧系统
在 LLM 出现前，对话式 AI 系统依靠庞大的逻辑树，根据语音输入对请求进行分流。这种方案常见于客服电话（如航空公司热线）和支付系统（如信用卡电话服务）。
这些旧系统响应缓慢，感觉像机器人，且只能接受极有限的人工输入。你很可能也有过类似经历：对着电话生硬地大喊“是”，以回答提示。糟糕的体验让大多数用户试图“击败系统”，强行转接真人客服。
不过，这些电话菜单有一个优势——边界明确。对话可走的路径有限，开发者也能轻松设置护栏，忽略不允许的输入。这种限制正是 LLM 优缺点的根源：它们大幅突破了电话菜单的局限，却也难以预测，打开了潘多拉魔盒，可能做出无法兑现的承诺、对客户发火，或泄露敏感数据。
默认缺口
如果只用原本为人类设计的手册训练 LLM，由于存在几个核心缺口，效果往往平平。理解这些缺口，有助于设计相应的提示词：
语气不匹配
LLM 通过强化学习训练，人类反馈会激励 LLM 返回结构化内容。具体而言，LLM 的回复往往冗长，包含大量项目符号、强调块和标题。
但在对话式 AI 场景中，LLM 需要模拟口语交流简洁、平铺直叙的特点。
假设缺口
LLM 倾向于用推断出的知识填补未知信息，而不是提出问题。这可能导致错误假设，误导用户，甚至造成代价高昂的失误（例如承诺退款）。稍后将介绍如何利用知识库和护栏，让 LLM 更有依据地作答，避免做出错误承诺或执行不允许的操作。
延迟
LLM 可以通过程序调用函数，代替人工收集和写入数据。这通常是 LLM 最大的优势之一，也意味着过去允许电话客服在执行任务时“争取时间”的培训指令已不再需要。不过，函数调用也并非瞬时完成，因此只要预计会有延迟，LLM 就需要准确提前告知用户（例如：“请稍等，我来查看一下你的情况。”）。
配置
个性
LLM 很擅长调整语气以匹配特定风格。可以将 LLM 配置为友好、幽默、简洁、正式，或结合多种风格。这是编写 LLM 提示词时的重要输入。
例如，为不满的航空公司客户提供支持的客服对话式 AI 应用，其开发者可能会使用如下提示词：
Nicole
格式
LLM 需要获得明确的回复指示。为确保不加入额外的填充文本，应提供一个结构来包裹传递给用户的回复。
例如，可以向 LLM 提示：
这种框架能促使 LLM 给出适合朗读的回复。
不过，LLM 有时会在一些看似与书面内容没有直观差异的地方出错。数字就是常见例子——LLM 可能会输出邮编 10023，导致 文本转语音模型读成“一万零二十三”。因此，应明确提示 LLM 逐个读出数字，并说明数字的含义，例如：“邮编是幺零零二三。”
温度
为对话式 AI 配置 LLM 时，温度是关键参数。较低的温度会生成更聚焦、更确定的回复，适合任务导向型对话；较高的温度则会生成更有创意、更多样的回复。
低温度适合偏好一致回复的对话式 AI 系统（例如退款客服热线）。而对于希望为客户提供更有吸引力、更真实体验的系统（例如数字教练），较高温度更合适：
High Temperature: Hey hey! You've landed at ElevenLabs support—ready to tackle your tech troubles! What's on your mind?
知识库
对于需要调用大量知识的对话式 AI 系统，应使用知识库来缩短提示词。在生产环境中，通常通过向量数据库（如 Pinecone 或 Elasticsearch）或 LLM 提供商的直接知识存储实现。
总体而言，知识库对于让 LLM 的回复基于经过批准的事实信息至关重要。构建对话式 AI 系统时，应为 LLM 提供全面的知识库，其中包含有关产品、服务、政策和流程的准确最新信息。这能防止 LLM 产生幻觉或编造信息，同时鼓励它在不同对话中给出一致、可靠的回复。
流程
由于 LLM 经常代替用户调用函数，也需要知道明确需要哪些输入。例如，如果 LLM 的工作是帮助用户预约理发，就需要确保已获得：
- 用户姓名
- 期望的日期和时间
- 用户地址
- 用户偏好的服务
简单的实现可能会让 LLM 在一轮对话中询问所有信息。作为文字内容，这完全没问题；但在对话中，可能会让人难以应对：
Customer: My name is Mathew and anytime Wednesday afternoon works. What else did you ask for?
信息通常通过对话逐步收集，因此必须鼓励 LLM 分步获取信息。这样能带来更自然的对话体验：
Customer: My name is Mathew Pregasen.
Support Agent: Thanks Mathew. When would you like to make an appointment?
Customer: Anytime on Wednesday afternoon works fine.
Support Agent: Great. Now can I get your address to find the nearest location?
Customer: 555 West Main Street
Support Agent: Perfect. Now what service are you look for?
Customer: I'm looking for a haircut and if you could also do my beard that would be great!
护栏
权限
构建分布式系统时，你会假设服务器终有一天会崩溃。同样，构建 AI 系统时，也应假设 LLM 终有一天会出错。为尽量缩小错误的影响范围，应只授予系统完成当前任务所需的最低权限。以下是一些做法：
- 正确设置读写权限：如果 LLM 只需从数据源读取信息，务必为其提供只读端点。
- 限制对 API 端点的访问：如果 LLM 只需访问特定端点，务必确保它无法访问其他端点。
- 人工介入升级：如果需要执行高风险操作，可考虑采用 人工介入 workflow，要求在执行操作前获得“经理批准”。
验证与核验
创建通过工具调用执行操作的对话式 AI 语音智能体系统时，建议内置验证与核验流程，确保收集到正确的用户信息。现在与人工客服交谈时，他们会重复你提供的关键信息，以确认自己听对了，也确认客户没有说错。LLM 同样可以从这种程度的错误检查中受益：
Customer: 555 West Main Street
Support Agent: I got five five five west main street. Did I miss anything?
为进行验证，应根据该类信息的常见结构检查从客户处收到的所有信息。电话号码的位数是否正确？客户提供的年龄是否在合理范围内？客户是否提供了有效地址？
Customer: 317-798-97289
Support Agent: I think I might have misheard you. I heard 11 numbers. Would you mind repeating that again?
可根据使用场景，核验收到的所有信息，或只核验未通过验证的信息。此外，也可以选择在每条信息传入时核验，或最后统一核验。
总结
要成功为对话式 AI 智能体系统编写提示词，需要平衡恰当的配置和护栏，以打造既像与真人交谈、又更高效的体验。这一过程并非简单地用旧培训材料提示 LLM；LLM 是需要专门结构和策略的工具，才能产生可预测、有效的结果。
