Multi-model prompt adaptation and tuning

[yhjun1026]

Different LLM models have different requirements for input structure and support for prompts and examples. We hope to optimize the overall design so that different models can perform better

[yhjun1026]

当前Prompt的使用流程：
1.prompt模板注册/DB-GPT/piolt/scene/xx场景/prompt.py 里 CFG.prompt_templates.update({prompt.template_scene: prompt}) 按场景注册了模板
2.模板加载在场景对话里/DB-GPT/piolt/scene/base_chat.py 里加载模板 ### load prompt template
self.prompt_template: PromptTemplate = CFG.prompt_templates[
self.chat_mode.value()
]

[yhjun1026]

多模型模板的改进思路，如果某个模型需要独立定义，新加一个prompt_xx.py 然后注册到对应场景对应模型名称下， 加载时特定模型有定义用模型自定义promot 没有使用默认prompt

[fangyinc]

是的，感觉场景 prompt 这块可以考虑抽象一套接口了，多模型，多语言支持。

[yhjun1026]

多语言适用于简单对话场景， 复杂任务的估计不太好用

[fangyinc]

我感觉这个思路可以的，目前每个场景的prompt 都注册到了 CFG.prompt_templates 字典中，简单字典的结构目前不太够用，可以在Config中 增加一个 prompt_template_registry ，支持模型注册各个场景的 prompt，可以根据模型名称、场景名称和、系统语言（目前主要是中文和英文）来获取 prompt。

[yhjun1026]

另外一个模型输入适配， 需要dbgpt-server和llm-server交互是结构化的，而非文本化的。

[fangyinc]

我看模型目前是通过 llmserver.py 的接口调用了，如果想要结构化的交互，这里的接口就得是结构化的。

[yhjun1026]

对的，因为结构化后 多模型适配解析更容易。 否则现在需要先拆文本，看起来有点蠢

[fangyinc]

关于结构化的prompt这块，仔细看了看代码，base_chat，将所有的prompt拼接成字符串了，这里可以新增一个方法 generate_llm_messages, 将prompt放到python 字典list中，格式可以考虑使用openai 的接口的格式：

messages =  [  
  {'role':'system', 'content':'You are an assistant that speaks like Shakespeare.'},    
  {'role':'user', 'content':'tell me a joke'},   
  {'role':'assistant', 'content':'Why did the chicken cross the road'},   
  {'role':'user', 'content':'I don\'t know'}  
]

或者目前的格式：

messages =  [  
  {'role':'system', 'content':'You are an assistant that speaks like Shakespeare.'},    
  {'role':'human', 'content':'tell me a joke'},   
  {'role':'ai', 'content':'Why did the chicken cross the road'},   
  {'role':'human', 'content':'I don\'t know'}  
]

然后需要修改 base_chat 的参数 payload，新增一个 ”messages“ 字段，将generate_llm_messages 的内容写到这里(为了兼容可以先保留"prompt")

格式大概如下：

        payload = {
            "model": self.llm_model,
            "prompt": self.generate_llm_text(),
            "messages": self.generate_llm_messages(),
            "temperature": float(self.prompt_template.temperature),
            "max_new_tokens": int(self.prompt_template.max_new_tokens),
            "stop": self.prompt_template.sep,
        }

然后逐步修改每个模型的 generate_stream_func，支持直接取 "messages" 参数， 再同步修改一下 llmserver。

[fangyinc]

多模型的支持和部署还是挺复杂的：不同的prompt、多卡的支持，这里的工作很多fastchat已经做了，我们是不是可以考虑直接对接它，当然简单的私有化部署也很重要，它里面也有一些我们不需要的功能。

[yhjun1026]

你可以看下如果比较好集成的话可以直接的

[fangyinc]

由于多卡的问题，我最近使用DB-GPT大部分情况都是使用proxyllm 调用 fastchat 提供的 openapi 去调用的，基本上现在就是支持的，不过稍微有几个地方需要改改。

[fangyinc]

我理解来看，这属于一个架构设计的问题，如果确定直接对接fastchat 完全ok的话确实我们可以少花点精力在模型的集成和部署上，专注场景的开发，真需要改部署细节的可以提到fastchat。

[fangyinc]

这个问题可以后面开一个讨论~

[fangyinc]

@yhjun1026 如上，目前主要两个点：

1. 多模型 prompt
2. 结构化模型输入

如果没别的问题的话我可以开发这两个功能，分两个pr提。

[yhjun1026]

可以，干吧

[kinthaiofficial]

Multi-model prompt adaptation for database-aware agents is a nuanced problem because the "right" SQL generation prompt varies significantly across model families, not just across models within a family.

A few things that matter:

Few-shot examples are model-specific — the optimal few-shot examples for GPT-4 SQL generation aren't the same as for Llama 3 or Claude. GPT-4 benefits from concise examples with clear table/column naming; smaller models often need more verbose examples that spell out the reasoning.

Schema formatting matters — some models perform better with DDL-style schema (CREATE TABLE users (id INT, name VARCHAR...)), others with a more natural format (Table: users, Columns: id (integer), name (text)). Testing both formats adds 5-15% accuracy on most models.

Chain-of-thought vs direct — frontier models (GPT-4, Claude Opus) can reliably generate correct SQL directly. Mid-tier models benefit from being asked to reason through the query before writing it. This adds tokens but reduces errors.

Error recovery loops — multi-model systems should include a retry loop that catches SQL execution errors, feeds the error back to the model, and asks for a correction. This works better than one-shot generation for complex queries on any model.

Cost routing by query complexity — simple lookups and filters → fast cheap model; complex JOINs, CTEs, window functions → capable model. A complexity classifier (can be a regex heuristic) makes this automatic.

We've applied similar model routing for KinthAI's agent tool calls that include database operations: https://blog.kinthai.ai/agent-wallet-economic-models-autonomous-agents covers the routing economics; https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons the tool use patterns.

Is the prompt adaptation effort primarily for accuracy improvement, or for cost reduction by routing to cheaper models?