软件项目里的 prompt engineering 怎么做能有点技术含量？

我们组是做一些原型软件开发。现在肯定离不开模型了。所以本地的小的模型，服务器的大的模型都用。
我前一阵子围绕一个小的模型做一些周边的数据处理，觉得还有一些发挥的空间，体现一些工作量。
最近转到围绕语言模型，比如发一段文字，让模型给一些总结判断，提取一些信息什么的。之前我们组其他人也在做这些，我一直觉得水分很大，就是根据一些准则，自己东试试西试试，在一个dataset里评估下哪个好。
轮到自己做了，有没有比较严谨的办法来找到比较好的prompt?

format of prompt 也会影响准确率 https://arxiv.org/pdf/2310.11324

觉得prompt engineering 很适合拿来当intern projects

爱讲笑话 发表于 2025-4-19 15:03
举个例子，在一段话中找出有几个人在交谈。
比如我写一个prompt, 正确率30%，修改修改，40%，
这类问题 ...

好问题 这个上限你很难看得出来因为use case不一样 但是general 来说 prompt engineering之上是fine tuning。只能说你们自己内部设一个threshold如果达到了这个标准就不用fine tuning 如果再怎么prompt engineering都达不到那老老实实fine tuning.  然后怎么去一下调一个好的Prompt？并不是瞎搞的 有一个系统化的方法论 objective -> goal -> context -> few shot -> CoT -> few shot CoT -> adjustment

prompt engineering 是不是也可以从下面的这些角度去探索
1. evaluation pipeline, 怎么多快好省的搭建更好的 benchmark 来做 evaluation
2. auto prompt, 不用减少迭代，而是转化成一个类似 HPO 的问题去自动的找到效果最好的 prompt (同时也 depends on 1)
3. prompt managament & selection, 在不同的场景下不同的 prompt (比如 format 不一样) 会有不同的效果，是不是可以针对具体的 request 来优化 prompt

prompt engineering只能慢慢调了 一般系统化都大差不差

Euclidc 发表于 2025-4-19 14:12
prompt engineering只能慢慢调了 一般系统化都大差不差

举个例子，在一段话中找出有几个人在交谈。
比如我写一个prompt, 正确率30%，修改修改，40%，
这类问题，估计上限准确率能到多少？有什么比较有迹可循的办法来摸索？

看我周围同事做类似的事情，都是参考一些prompt的原则然后试，有点像胡乱猜测和撞大运。

Euclidc 发表于 2025-4-19 15:35
好问题 这个上限你很难看得出来因为use case不一样 但是general 来说 prompt engineering之上是fine tuni ...

多谢！
凑足八个字

爱讲笑话 发表于 2025-4-19 15:36
多谢！
凑足八个字

要点米 不过分吧QAQ

Euclidc 发表于 2025-4-19 15:38
要点米 不过分吧QAQ

怎么给你米? 从没用过这个功能。

可以reference anthropic 的这个采访 https://www.youtube.com/watch?v=T9aRN5JkmL8

some points

优秀的提示工程师需要具备清晰的沟通技巧，能够清晰地表达和理解任务. 他们还需要乐于迭代提示，分析误解并进行改进. 思考提示可能遇到的边缘情况和不寻常的输入至关重要. 仔细阅读模型输出被认为是理解模型如何处理指令的关键. 此外，还需要能够理清自己的假设，并清晰地向模型传达完成任务所需的完整信息.

优化提示是一个与模型来回互动以完善信息的过程. 经常需要发送数百个提示才能达到预期结果. 一项关键技术是要求模型识别指令中不明确或不清晰的部分. 当模型出错时，询问它出错的原因以及如何改进指令通常非常有效.

提示工程在不断发展，过去有效的技巧可能会被训练到模型中. 目前的趋势是信任模型并提供更多信息和背景. 未来，模型可能会更多地协助用户进行提示工程，进行更高带宽的交互. 模型可能会主动向用户询问信息以明确需求. 核心在于外化自己的大脑，清晰地将复杂的想法传达给模型.