作者: peirongyan | 公司: 腾讯
开头直接说重点，本文提出一种称之为inner tools的大模型范式，核心思想是将部分无需网络调用的通用工具在模型基座中直接实现并使用，预计可以解决大模型超长上下文理解以及大模型实际应用中消耗资源多，耗时长的问题。
背景
在实践中，使用codebuddy等ai coding工具时会发现在提问后大模型会逐步调用代码检索工具查询代码块（只传代码块这种工程实现主要是为了减少上下文，尤其是在仓库比较大的情况），一些代码逻辑较复杂的场景，大模型通常需要多次调用才能清晰的了解实现逻辑，这就会导致在一个问题上agent层与模型层会有多次网络传输，每一次agent层都要重新调用大模型，这部分输入token会一直算钱，消耗资源的同时还会导致耗时增加。这种问题在ima等知识库工具中同样存在。
解决方案
事实上，这个代码块检索的能力可以直接在大模型层支持，在常规输入给到大模型的同时，增加额外的参数将代码仓库作为内部知识（inner_knowledge）一起传给大模型，大模型在输出token时，判断是否为检索代码库的标签，是的话中断预测并调用本地检索工具，直接检索输入的inner_knowledge，并将检索结果直接加在上下文中继续预测输出token，如此迭代，直至最终返回。
这种能力不仅可以支持代码库，同时对于文档、报告、法律合同等超长文本的情况同样适用，可以统一支持为内部知识检索工具（inner_search）。进一步拓展，对应其他无需网络请求的工具调用，均可以转换为内部工具调用（inner tools），例如数学运算、部分代码执行、图片生成等。（某种意义上讲，这样的实现方式大模型可以说在数学问题上的表现近似达到上限，不过是以一个非常规的方式）
具体技术方案
这里给出一个本人想到的最简实现方案，当然不排除有其他更合适的技术方案，这个方案的核心是将inner tools视为正常的function call工具能力，只在function名称中增加前缀标识"inner_tool_"，例如inner_search对应function名称即为inner_tool_inner_search。
下面就以inner_search为例详细介绍下：
- 首先在大模型调用协议上增加inner_search工具需要的参数（其他工具不需要这步），对应结构为：
```json
"inner_search_paras": {
"desc": "知识库描述，比如：这是服务对应的代码仓库",
"knowledge": "知识库内容，对应代码仓库的代码文件等"
}
```
- 大模型层在获取到用户输入后，需要将提供的inner tools列表添加到输入的tools列表里，对应在function的名称前增加前缀标识"inner_tool_"，对于inner_search来说还需要根据参数里的描述desc来修改function的描述，示例如下：
```json
messages = [
{"role": "system", "content": "你是个编程助手"}, // 系统提示词
{"role": "user", "content": "你好"}, // 历史提问
{"role": "assistant", "content": "你好，有什么能帮到你呀"}, // 历史回答
{"role": "user", "content": "这个服务有什么功能"}, // 最新提问
]
tools = [{
"type": "function",
"function": {
"name": "get_weather", // 用户输入的工具
"description": "Get current weather information"
}
},{
"type": "function",
"function": {
"name": "inner_tool_inner_search", // 增加的inner tool
"description": "内部知识检索工具，知识描述：{inner_search_paras.desc}" // 根据输入参数的知识描述填充对应function描述
}
}]
```
-
现在准备工作已经做完，接下来在模型输出的时候实时检测对应生成的token对应是否是工具调用，如果是就根据判断function名称判断是否为内部工具，进而调用工具并中断模型输出。这个过程由于是本地执行，理论上是非常快的。
-
在工具调用完成后，将工具调用结果（这里对应是代码块列表）加在上下文中，并让模型继续预测直至最终输出完成。
对应其他inner tools也可以参考这个方式实现。
优点
-
inner tools的方式可以显著减少对大模型的调用次数和耗时，而且不会影响表现效果。
-
inner_search工具的实现可以解决超长上下文的情况，inner_knowledge可以非常大，而且不会占用上下文长度，在模型层可以灵活检索并增加在上下文中。
-
提供的这种实现方式，不需要对大模型本身进行调整和训练，只需要在模型部署层修改代码即可，可以很快适配。
总结和展望
以上是Inner Tools范式提出的过程和具体实现方案，后续我将基于deepseek开源代码提供一个简单的demo附在文章里。