您已经体验了。当Chatgpt具有令人难以置信的力量时,这种挫败感的响应方式还是令人感到沮丧的。也许它过于言行,过于道歉,怪异的开朗或顽固地回避。尽管我们可能会开玩笑地称其为“令人讨厌的个性”,但根本不是个性。这是培训数据,安全协议和固有性质的复杂组合 大型语言模型 (LLMS)。
您的控制权比您想象的要多。
Chatgpt为什么会这样行动?
了解“为什么”如何帮助更好地制作”方法提示。 Chatgpt的怪癖通常源于:
- 培训数据影响: chatgpt 从大量的互联网文本中学到的,包括论坛,文章,书籍和网站。它吸收了该数据中存在的一些陈词滥调和陈词滥调。
- 从人类反馈(RLHF)中学习的强化: 人类在培训期间对AI的回答进行了评估,教会其有用,无害和诚实。这个过程非常偏爱礼貌,明确表示其AI的性质(“作为AI模型……”)以及谨慎的措辞,这有时会导致过度的对冲或道歉。
- 安全护栏: 为了防止有害,不道德或不适当的产出,已制定严格的安全协议。尽管必不可少,但有时这些可能会导致AI拒绝看似无害的请求或过于谨慎,以最具风险的方式来解释提示。
- 预测性质: Chatgpt以您的提示及其培训来预测最统计学上的下一个单词(或令牌)。它不会像人类那样真正“理解”上下文或细微差别,如果提示不够具体,则会导致误解或通用输出。
- 迅速解释: 它的性能在很大程度上取决于它的清晰解释您的说明。歧义会导致不可预测的结果。
常见的chatgpt烦恼以及如何设计更好的回应
让我们通过特定的及时工程技术来解决一些频繁的挫败感:
1。冗长
描述: 句子足够时获得段落;简单概念过于详细的解释。
可能原因: 培训数据通常包括详细的解释; RLHF可能会倾向于彻底。
修复程序: 明确有关长度和格式。
"Explain [topic] concisely."
"Summarize the key points in 3 bullet points."
"Answer in a single sentence."
"Limit your response to under 100 words."
"Provide a brief overview of [topic]."
例子:
而不是: “告诉我有关光合作用的信息。”
尝试: "Explain photosynthesis in two sentences suitable for a 5th grader."
2。不断的对冲和道歉
描述: 诸如“作为AI语言模型”,“注意……”,“我不能……”,“我为任何混乱歉意……”之类的短语,即使在不必要的情况下也是如此。
可能原因: RLHF和安全培训强调局限性和礼貌。
修复程序: 指示它是直接的,并假设用户理解。
"Answer directly without hedging."
"Do not apologize or state you are an AI."
"Provide the information without qualifiers like 'it's important to note'."
"Assume I understand the limitations of AI models."
"Be confident in your response."
(谨慎使用,如果主题复杂,可能会增加幻觉风险)。
例子:
而不是: “ Python有什么好处?”
尝试: "List the main benefits of Python for web development. Answer directly, without apologies or stating you're an AI."
3。不需要的语气
描述: 音调与上下文不符 – 也许对一个严肃的话题也太热情,或者太僵硬而无法创造性地集思广益。
可能原因: 试图维持从RLHF衍生出的普遍有用和积极的角色;默认为标准音调而没有特定的说明。
修复程序: 明确定义所需的音调或角色。
"Adopt a formal and professional tone."
"Write in a neutral, objective style."
"Use a casual and friendly tone."
"Respond with the tone of an expert [field specialist]."
"Avoid excessive enthusiasm or exclamation points."
例子:
而不是: “解释量子纠缠。”
尝试: "Explain quantum entanglement in a neutral, scientific tone suitable for a college student. Avoid analogies that are overly simplistic."
4。通用或明显的信息
描述: 当您需要特定的细节或更深入的见解时,接收基本的表面级答案。
可能原因: 模棱两可的提示;模型默认为培训数据中经常发现的常识。
修复程序: 提供上下文,指定所需的细节级别,并要求提供细节。
"Provide specific examples of [concept]."
"Focus on the [specific aspect] of [topic]."
"Assume I have foundational knowledge; explain the advanced aspects."
"Instead of a general overview, discuss the challenges of implementing [technique]."
"Analyze the pros and cons from the perspective of a [specific role]."
例子:
而不是: “如何提高网站速度?”
尝试: "List 5 specific, actionable techniques to improve website loading speed, focusing on image optimization and server response time. Explain the technical implementation briefly for each."
5。石墙或无助的拒绝
描述: 拒绝以安全性或限制为由回答一个看似无害的问题。
可能原因: 安全护栏将请求解释为潜在问题,即使不是;访问实时数据或执行某些操作的限制。
修复程序: 重塑,简化或专注于基本原则。
- 改性: 以不同的方式提出问题,避免潜在的触发单词。
- 分解: 要求原始请求的较小,较不复杂的部分。
- 要求原则: 而不是要求潜在的敏感细节,而是要求涉及的一般规则,概念或步骤。例如,而不是“将代码写入访问X系统”,而是尝试“解释访问X等系统的常见方法和安全注意事项”。
- 检查约束: 是关于实时数据(如今天的股票价格)还是个人意见的请求?承认您知道它不能做这些事情,而是询问相关的历史数据或共同的观点。
例子:
如果被拒绝: “为新型无人机制定营销计划。”
尝试重新设计: "Outline the key components of a typical marketing plan for a high-tech consumer product. Include sections like target audience analysis, channel strategy, and budget considerations."
6。忘记上下文或说明
描述: 忽略对话的先前部分或同一聊天会话中前面给出的说明。
可能原因: 有限的上下文窗口(它可以一次“记住”多少文本);难以跟踪复合物,多转弯说明。
修复程序: 定期加强上下文和指示。
- 总结: 在提出一个新的相关问题之前,简要重述关键上下文或以前的几点。
"Given that we previously established X and Y, now explain Z."
- 使用明确的参考:
"Based on the criteria you listed earlier..."
- 自定义说明(如果有): 使用自定义说明功能提供持久的背景信息和输出偏好。
- 保持会议的重点: 对于非常复杂的任务,请考虑启动新的聊天会话以确保清洁上下文板岩。