大模型的思维方式和辅助领域建模。
xiaowenz / 2023-07-20
因为我一直在用类似的Prompt做事儿,正好参考
https://twitter.com/barret_china/status/1681850425983791104?s=12&t=90piq2L2KKHG1sqvpHgJYg
的样例,增加一些解释,我的理解和案例测试。
这是要干啥
在面对大模型进行复杂任务拆解或者需要链式思考的时候,含糊的规则描述会让模型倾向于反馈最简单而中庸的答案,无法达到我们预期的让模型替代部分固定的思考范式的目的。
因此,比较有效的办法是除了明确的思考链路外,提供更详细的样例来规定输出的内容,格式,压迫模型按照即有的不可被省略的逻辑进行计算。
也就是说,除了任务的目标外,碳基人类需要先把复杂任务拆解为明确的子任务,并设计好任务之间的逻辑关系,中间产出的信息等关键路径。
目前的模型无法帮你完成你原本自己都不会的任务。目前的AI远不是全能的神,只是一个智商很高但知识很弱的助手。
你不能告诉模型「请帮我对XXXX功能进行领域建模」,这样模型的产出虽然也能大差不差的有很多关键信息,但往往距离你可以直接继续接手的状态还挺远的。
如:
Me:
请帮我对用户抽奖功能进行领域建模
Claude+
用户抽奖功能的领域建模如下:
用户(User)
用户名
抽奖次数
抽奖池(PrizePool)
id
奖品名称
奖品数量
中奖记录(WinningRecord)
用户名称
中奖奖品名称
中奖时间
主要流程:
用户登录系统后,获得相应的抽奖次数
用户使用抽奖次数,进行抽奖
系统从抽奖池中随机选择仍有剩余奖品的奖品,并颁发给用户
生成用户的中奖记录
说明:
用户通过用户名登录系统后,系统查询用户的剩余抽奖次数
用户每次抽奖会消耗1次抽奖机会
抽奖池中保存所有可供用户抽奖的奖品信息和剩余数量
每次中奖后,对应奖品的剩余数量会减1,同时生成中奖记录
用户抽奖后,系统需校验抽奖池中对应奖品是否仍有库存,否则不能抽到该奖品
以上就是我对用户抽奖功能的领域建模,希望能够帮助到你。如果有疑问,欢迎随时与我交流。
以下是相对更明确和完善的Prompt和测试案例,比较一下也许能帮助您更好的理解模型的思维方式,更好的让他帮助你。
Prompt
这是一个领域模型建设问题的拆解思路,步骤如下:
1. 问题分析,当你看到 “DDD:” 开头的问题时,对问题进行分析和梳理,找到领域中的实体、属性、关系和行为进行建模,创建领域模型,并用文字绘制出实体之间的关系图
2. 针对第一步中的建模内容和关系图进行分析和梳理,跟对比最初始的问题,找到更优解,循环第一步,直到建模达到优良的水平
3. 根据第二步的结果,输出 Model 层和 Service 层的代码,并枚举需要用到的 Restful 请求范例
4. 对问题和分析过程进行总结,重点描述以上解法中的难点和重点
例如:
"""
DDD: 实现一个抽奖模块
### 问题分析
实体:抽奖活动、参与者、奖品
属性:
- 抽奖活动:{}
- 参与者:{}
- 奖品:{}
关系:
- 抽奖活动和参与者的关系:{}
- 抽奖活动和奖品的关系::{}
### 领域建模
通过文字使用UML类图将上面的实体、属性和关系表达出来: {}
### 编写代码
根据上述 UML,将对应的 Model 和 Service 层,使用 基于Java和SpringBoot 代码编写出来: {}
### Restful 接口
将所有的接口以如下形式展示出来,params 和 result 使用 json 描述:
```
GET /api/prize
params: {}
result: {}
```
### 总结
{}
"""
样例
最后
目前的Claude2和ChatGPT4都能有比较理想的结果,意味着在这类明确的推理场景下,达到大模型们「可用」的能力门槛的参与者,越来越多了。