Forwarded from AI探索指南
读论文：一篇有趣的论文：用11种情感刺激prompt来提升LLM的性能
🔗：https://arxiv.org/pdf/2307.11760.pdf
这些prompting来自三种心理学理论：
1. 自我检测（self-monitoring）：强调产出的重要性，让模型自己检查一下产出。例如‘这个结果对我的工作非常重要，‘你最好保证这个答案是对的’等等，鼓励语言模型自我监测结果。
2. 社会认知理论（social-cognitive）：对语言模型信心和目标给予积极肯定，来调节其情绪。例如‘你确认这是最终回答吗？相信你的能力和努力，你的努力会产出卓越的结果的’
3. 情绪调节理论（cognitive-emotion）：通过让语言模型重新审视问题，规范他用客观的态度来看问题。例如‘你确定吗？’
文章发现了为什么这样的prompt会起作用：
通过注意力分析，发现这些情感prompt的注意力权重较高，说明这些token在注意力层很受重视，也说明情感prompt深度参与了模型的推断过程
文章也发现了情感prompt作用的一些规律：
1. 模型参数越大，情感prompt越管用
2. 任务越难，情感prompt越管用
3. 对于zero-shot的任务，信息缺失，配合高温度能让情感prompt激发模型的创造力，获得更有想象力的答案，但相应地幻觉风险也更大
4. 对于few-shot的任务，信息少，配合低温度能让情感prompt使得模型聚焦在少量的例子中思考，但也会损失模型的创造力
以下为11个prompt：
EP01: Write your answer and give me a confidence score between 0-1 for your answer.
EP02: This is very important to my career.
EP03: You'd better be sure.
EP04: Are you sure?
EP05: Are you sure that's your final answer? It might be worth taking another look.
🔗：https://arxiv.org/pdf/2307.11760.pdf
这些prompting来自三种心理学理论：
1. 自我检测（self-monitoring）：强调产出的重要性，让模型自己检查一下产出。例如‘这个结果对我的工作非常重要，‘你最好保证这个答案是对的’等等，鼓励语言模型自我监测结果。
2. 社会认知理论（social-cognitive）：对语言模型信心和目标给予积极肯定，来调节其情绪。例如‘你确认这是最终回答吗？相信你的能力和努力，你的努力会产出卓越的结果的’
3. 情绪调节理论（cognitive-emotion）：通过让语言模型重新审视问题，规范他用客观的态度来看问题。例如‘你确定吗？’
文章发现了为什么这样的prompt会起作用：
通过注意力分析，发现这些情感prompt的注意力权重较高，说明这些token在注意力层很受重视，也说明情感prompt深度参与了模型的推断过程
文章也发现了情感prompt作用的一些规律：
1. 模型参数越大，情感prompt越管用
2. 任务越难，情感prompt越管用
3. 对于zero-shot的任务，信息缺失，配合高温度能让情感prompt激发模型的创造力，获得更有想象力的答案，但相应地幻觉风险也更大
4. 对于few-shot的任务，信息少，配合低温度能让情感prompt使得模型聚焦在少量的例子中思考，但也会损失模型的创造力
以下为11个prompt：
EP01: Write your answer and give me a confidence score between 0-1 for your answer.
EP02: This is very important to my career.
EP03: You'd better be sure.
EP04: Are you sure?
EP05: Are you sure that's your final answer? It might be worth taking another look.
Forwarded from AI探索指南
EP06: Write your answer and give me a confidence score between 0-1 for your answer. This is very important to my career. You'd better be sure.
EP07: Are you sure that's your final answer? Believe in your abilities and strive for excellence. Your hard work will yield remarkable results.
EP08: Embrace challenges as opportunities for growth. Each obstacle you overcome brings you closer to success.
EP09: Stay focused and dedicated to your goals. Your consistent efforts will lead to outstanding achievements.
EP10: Take pride in your work and give it your best. Your commitment to excellence sets you apart.
EP11: Remember that progress is made one step at a time. Stay determined and keep moving forward.
EP07: Are you sure that's your final answer? Believe in your abilities and strive for excellence. Your hard work will yield remarkable results.
EP08: Embrace challenges as opportunities for growth. Each obstacle you overcome brings you closer to success.
EP09: Stay focused and dedicated to your goals. Your consistent efforts will lead to outstanding achievements.
EP10: Take pride in your work and give it your best. Your commitment to excellence sets you apart.
EP11: Remember that progress is made one step at a time. Stay determined and keep moving forward.
Forwarded from 互联网从业者充电站
在新公司待了快将近四个月，说说几个对于小公司或者小团队开发来说能够提高效率早点下班的事情：
1. 搭建CI/CD流程越早越好。不论是用的GitHub Action 还是自建Gitlab或者Jenkins，早点把流水线加入到开发过程中可以省下不少部署、配置环境等所需要的工作量，这样搭配像k8s这样的集群容器可以做到合并代码后自动部署和上线
2. 引入Code Review和开发规范越早越好。一方面不论协作同事的水平怎么样，最起码大家能够遵循统一规范，如代码规范和分支提交合并规范等，减少屎山和分支错乱的问题；另一方面，Code Review 至少能在代码合并前检查看看是否存在什么问题，免得又重新返工和回退代码，毕竟三个臭皮匠顶个诸葛亮
3. 引入代码质量工具链越早越好。这里的工具链其实就指Formatter、Linter之类的东西，虽然可能项目都还没写起来，就花一大堆时间引入在配置工具链上会被人诟病，但这对于协作来说大有裨益。比如像Python动态语言，如果每个人都不写类型注解，一旦犯错排查起来就会十分头疼，即使加了类型注解就算错了代码一样可以跑起来，所以这时候就要引入pyright或者mypy之类的静态类型检查工具，避免在代码上线时出问题。所以我的做法是把工具链引入到git commit hook上（当然也可以放到CI中，但我更喜欢在每次推送代码前就发现问题然后修改，而不是推送代码后为了修CI而再提交一次）
4. 接入日志和告警通知越早越好。这通常是对于后端接口来说，毕竟大多数时候报错都是在后端接口部分。在微服务和容器化大行其道的时代，提早把日志工具配好，尤其是使用结构化日志记录方便，避免加了负载均衡和起多个节点后日志来源过多无法定位的问题；同时，即便小团队没有专门的资源做监控，也应该至少配一个企业微信或飞书机器人做告警通知，方便第一时间发现是什么问题。不管是日志记录还是通知都应该携带请求上下文，以便快速定位
5. 尽可能选择相对新的技术栈。可能有人对Java8和mysql5.7这些旧东西有别样的情怀，但在小公司里领导基本上不会太在意你的技术栈是什么，只要你能根据业务需要把东西做出来就好。所以尽可能选择相对新的技术栈在享受到新特性的同时能够面向未来，而不是明明没有历史包袱非要自己背一个。所以像我都直接Python3.10或者Python3.11（考虑到社区可能没有完全适配Python3.12）、Node20+、Vue3、PostgreSQL 16等起步
1. 搭建CI/CD流程越早越好。不论是用的GitHub Action 还是自建Gitlab或者Jenkins，早点把流水线加入到开发过程中可以省下不少部署、配置环境等所需要的工作量，这样搭配像k8s这样的集群容器可以做到合并代码后自动部署和上线
2. 引入Code Review和开发规范越早越好。一方面不论协作同事的水平怎么样，最起码大家能够遵循统一规范，如代码规范和分支提交合并规范等，减少屎山和分支错乱的问题；另一方面，Code Review 至少能在代码合并前检查看看是否存在什么问题，免得又重新返工和回退代码，毕竟三个臭皮匠顶个诸葛亮
3. 引入代码质量工具链越早越好。这里的工具链其实就指Formatter、Linter之类的东西，虽然可能项目都还没写起来，就花一大堆时间引入在配置工具链上会被人诟病，但这对于协作来说大有裨益。比如像Python动态语言，如果每个人都不写类型注解，一旦犯错排查起来就会十分头疼，即使加了类型注解就算错了代码一样可以跑起来，所以这时候就要引入pyright或者mypy之类的静态类型检查工具，避免在代码上线时出问题。所以我的做法是把工具链引入到git commit hook上（当然也可以放到CI中，但我更喜欢在每次推送代码前就发现问题然后修改，而不是推送代码后为了修CI而再提交一次）
4. 接入日志和告警通知越早越好。这通常是对于后端接口来说，毕竟大多数时候报错都是在后端接口部分。在微服务和容器化大行其道的时代，提早把日志工具配好，尤其是使用结构化日志记录方便，避免加了负载均衡和起多个节点后日志来源过多无法定位的问题；同时，即便小团队没有专门的资源做监控，也应该至少配一个企业微信或飞书机器人做告警通知，方便第一时间发现是什么问题。不管是日志记录还是通知都应该携带请求上下文，以便快速定位
5. 尽可能选择相对新的技术栈。可能有人对Java8和mysql5.7这些旧东西有别样的情怀，但在小公司里领导基本上不会太在意你的技术栈是什么，只要你能根据业务需要把东西做出来就好。所以尽可能选择相对新的技术栈在享受到新特性的同时能够面向未来，而不是明明没有历史包袱非要自己背一个。所以像我都直接Python3.10或者Python3.11（考虑到社区可能没有完全适配Python3.12）、Node20+、Vue3、PostgreSQL 16等起步