Prompt IDE:修订间差异

来自WHY42
无编辑摘要
第9行: 第9行:


= 项目起源 =
= 项目起源 =
这个想法最初源自于公司2023年7月份的黑客马拉松活动,当时,笔者Solo了一个叫做[https://ksogit.kingsoft.net/YES_CLUB_Hackathon/First-OpenAI/prompt-native ”Prompt Native“]的项目。什么是Prompt Native呢?有三层含义
这个想法最初源自于公司2023年7月份的黑客马拉松活动,当时,笔者Solo了一个叫做[https://ksogit.kingsoft.net/YES_CLUB_Hackathon/First-OpenAI/prompt-native ”Prompt Native“]的项目。什么是Prompt Native呢?有三层含义<ref>https://ksogit.kingsoft.net/YES_CLUB_Hackathon/First-OpenAI/prompt-native/-/blob/master/docs/showcase.docx</ref>:


The Three Meanings of “Native”
* Colud Native: 将大模型的能力做成云原生的FaaS
Colud Native: Since it’s server side application, cloud-native is currently the best approach. Think about each prompt to be an independent small application (ie. an API), then it’s naturally a Function in FaaS.
* Native Editor: 原生的提示词开发编辑器,也就是今天的Prompt IDE
Native Editor: No fake editors, No notepad, we developers want a real editor. Better to have all the features that a programming language should have, including versioning, debugging, etc.
* Native Tooling: 通过原生的大模型工具链来辅助我们开发
Native Tooling: Will it be a good idea to use GPT to teach us on it’s own usage?


<ref>https://ksogit.kingsoft.net/YES_CLUB_Hackathon/First-OpenAI/prompt-native/-/blob/master/docs/showcase.docx</ref>
大致的设计是这样:
 
# 通过一个Vs Code插件来开发提示词,提示词最终存储为一个文件,有这特定的格式。这就是Native Editor
# 在开发提示词的过程中,可以通过大模型给出提示词调优的建议,类似与Js Lint,我们可以做一个Prompt Lint,不过当时经过测试发现效果并不好;还有比如自动生成人设,例如[https://huggingface.co/merve/chatgpt-prompt-generator-v12 chatgpt-prompt-generator-v12]通过一个预训练的BART模型自动生成提示词,也可以集成到插件中,做到自动补全。这是Native Tooling
# 提供不同语言的FaaS模板和解析运行Prompt文件的库,将其部署到Kubernetes中为云函数。当时采用Knative Functions和Rust实现了一个简单的模板[https://ksogit.kingsoft.net/YES_CLUB_Hackathon/First-OpenAI/prompt-native/-/tree/master/examples/hello-world Hello World]
 
但是笔者当时犯了一个极大的错误,就是低估了这件事的难度。尽管在肝几天可以做出一个PoC,但后来发现,要做到”可用“的程度,其实是非常困难的。

2024年1月16日 (二) 05:14的版本

你是怎样调提示词的呢?这看起来是个再简单不过的问题,但对于开发者而言,一直缺乏一个趁手的工具。目前可以用的这些工具大致有以下的问题:

  • 可以同大模型聊天,但是不具备调参能力,例如ChatGPT、文心一言、ChatHub
  • 可以调参,但只支持特定的厂商,例如GPT Playground、Minimax体验中心等
  • 可以调参,也支持不同的厂商,功能也很强大,唯一缺点是不是原生的,如KPP
  • 啥都可以干,但是要写代码,例如LangChain

于是为了解决这个问题,能够更愉快地测试提示词,笔者撸了一个Vs Code插件——Prompt IDE。目前,尽管缺胳膊少腿,Prompt IDE初具雏形。在这个有趣的过程中,学习到了Vs Code插件开发的一些技巧,也对Vs Code的强大有了更深的认知,在这里简单总结一下。

项目起源

这个想法最初源自于公司2023年7月份的黑客马拉松活动,当时,笔者Solo了一个叫做”Prompt Native“的项目。什么是Prompt Native呢?有三层含义[1]:

  • Colud Native: 将大模型的能力做成云原生的FaaS
  • Native Editor: 原生的提示词开发编辑器,也就是今天的Prompt IDE
  • Native Tooling: 通过原生的大模型工具链来辅助我们开发

大致的设计是这样:

  1. 通过一个Vs Code插件来开发提示词,提示词最终存储为一个文件,有这特定的格式。这就是Native Editor
  2. 在开发提示词的过程中,可以通过大模型给出提示词调优的建议,类似与Js Lint,我们可以做一个Prompt Lint,不过当时经过测试发现效果并不好;还有比如自动生成人设,例如chatgpt-prompt-generator-v12通过一个预训练的BART模型自动生成提示词,也可以集成到插件中,做到自动补全。这是Native Tooling
  3. 提供不同语言的FaaS模板和解析运行Prompt文件的库,将其部署到Kubernetes中为云函数。当时采用Knative Functions和Rust实现了一个简单的模板Hello World

但是笔者当时犯了一个极大的错误,就是低估了这件事的难度。尽管在肝几天可以做出一个PoC,但后来发现,要做到”可用“的程度,其实是非常困难的。