B端业务场景提示词撰写的一些实践感悟
在B端业务场景中,AI大模型的应用已经逐渐普及,但如何高效地利用这些模型来满足复杂的企业级需求,仍然是一个需要不断探索的课题。本文通过作者在实际工作中的实践经验,深入探讨了如何撰写高质量的提示词,以提升AI模型在B端业务中的应用效果。
实践感悟
语言的边界与模型的理解
语言本身具有惯性和连锁反应,总有理解发生歧义的空间。无法保证模型能立刻理解我们想要表达的意思,并精确执行不出错。这不像编程中的正则表达式,修改完立即生效,而是需要不断调整和优化。
专业需求的瓶颈
在处理企业级的专业需求时,尤其是对结果精确度、输出专业度要求高的任务,单纯依靠提示词+通用模型的效果会逐渐走到极限。突破这一瓶颈,往往需要引入模型微调、专业知识库或其他辅助技术,才能达到更高的专业水准,提示词也不是万能的。
提示词诊断能力的成长
随着经验积累,我发现自己已经能够凭直觉发现提示词中的问题所在。下一阶段的成长目标是:记录每次发现问题时的修改过程,分析为何特定的修改能让模型按要求输出,从而总结出一套系统化的识别和修改方法。
提示词撰写技巧
结构化输出的稳定性
当模型输出结果不稳定时,可以尝试用JSON格式或Markdown格式来构建提示词中的表格结构,引导模型按照特定结构生成和填写内容。
注意事项:输出Markdown格式在前端渲染时,可能会出现显示异常。建议在提示词中特别说明,要求模型确保输出结果可以在前端正常显示。
“言出法随”的精确表达
提示词基本可以做到在模型能力范围内”言出法随”,关键在于清晰表达我们的需求。
例子:我曾在提示词中以Markdown形式提供表格,要求模型将输出内容填入。但在实际使用中发现,表格的前端渲染总是失败,尽管Markdown格式本身没有错误。后来我在提示词中明确要求模型在输出表格时检查格式和前端渲染兼容性,解决了这个问题。
消除歧义,提高精确度
在模型能力范围内,如果输出不符合预期,通常是因为提示词表述不够清晰或存在理解歧义。
例子1:
– 初始提示词:审核【送出日期】和【落款日期】是否和【data】(可变参数)一致
– 问题:模型只判断两个日期是否相互一致,而非与参数一致
– 改进提示词:
– 审核【送出日期】是否和【data】(可变参数)一致
– 审核【落款日期】是否和【data】(可变参数)一致
– 结果:模型能够正确判断两个日期是否分别与参数一致
例子2:
– 初始提示词:审核2.2是否包含”……【data】……”
– 问题:即使文档2.2内容与要求不符,模型也会编造符合要求的内容
– 改进提示词:审核文档全文是否包含【直接写提醒文案内容,不带2.2前缀序号】,如果有,提取原文填到表格中;如果没有,表中直接填【无】
– 结果:模型能够正确审核文档中是否包含特定文案及日期
简洁与结构化的平衡
提示词应在表达清需求的前提下尽可能简洁和结构化:
简洁:过长的提示词可能导致模型难以判断任务重点,注意力分散,同时也会占用宝贵的上下文
结构化:便于自己修改和记录,也有助于模型理解需求
提示词的随意性越高(想到什么说什么),模型输出的不稳定性就越强。对于创意性任务,这可能不是问题;但对于要求稳定性和一致性的任务(如审核类或格式规范严格的任务),结构化的提示词至关重要。
重复任务的提示词优化
如果一项任务需要重复执行三次以上,最好设计一个能够产生稳定输出的提示词模板。可以提高工作效率和结果一致性。
不同模型的提示词响应特点
QWEN 2.5 72B
优势:
– 对提示词服从度高,能严格按要求执行任务
– 输出稳定性和一致性强
– 适合处理对输出内容和格式要求严格的任务
局限:
– 处理复杂多步骤任务时,输出深度和专业度不足
– 语义理解能力有限,难以识别复杂文本关系(如”合并”、”拆分”)
– 无法有效识别长文本中的错别字和政治敏感内容
DEEPSEEK R1
优势:
– 在创意型任务中表现出色
– 语义理解和情景分析能力强
局限:
– 处理长文本和复杂任务时,不能严格遵循提示词
– 倾向于在理解提示词基础上,用自己的思路寻找捷径
– 常常找到自由发挥的空间,可能偏离原始要求
希望这些实践经验能对你有所启发!
本文由 @Mrs.Data 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
- 目前还没评论,等你发挥!