AI 应用的建模
在金融场景里面，我们一直在探索如何对知识进行建模，过去几年，学术界和工业界都尝试了知识图谱的方案。
在金融领域，我们有过好几年的知识图谱尝试，比如使用图构建全参数化的产业链知识图谱。
但是落地的难度极大，特别是很难使用技术手段来大规模的构建图节点和关系的参数。由于金融场景对数据的严谨性和正确性要求很高，所以通常需要很大的人力进行输入，投入性价比不高，所以通常就用不起来，图谱最后也变成了一本静态的书。
当大模型时代来时，我们试着回到初心：我们怎么去对知识建模，然后利用知识进行推理判断，得出结论。
先不讨论显性的知识建模，我们认为大模型已经包含了大量的知识，也不讨论怎么利用知识进行推理，而是讨论 三大要素中的数据。知识应用的三大要素分别是： 知识，信息（大多数时候是数据），然后是结论。通常，有了知识和数据，一般人都会自然而然的得出结论。
如何利用数据？
我们从一个具体的问题出发，比如我对与web3 提供了10个 Dex去中心化交易所的api。我们如何让这些api喂给AI，让用户能够尽可能的用text去查询这些api。并且能够组合这些api，并画出图来。
- 1.我们直觉的想法： 我给这些api做 详细的文档描述，喂给AI。也就是N个api做N个描述，来了一个text，就让AI去选择匹配的。
- 在1的基础上，我人为的去扩展，然后尽可能的穷尽参数的组合，衍生出更多的API，在加上描述。将N个API扩充为N平方个API的。
- 2的基础上，需要大量的人力，而且效果不一定是太好。并且还无法解决API组合来服务更加复杂的场景的问题。为了解决一些复杂的场景，并保证正确性，通常我们写一些模版，但是也依赖大量的人工输入。
Data Copilot的API 设计思路
- 逆向思维，从大量依赖人工，转而依赖AI 自身。
- 有一个api，我们先定义最常用的query。比如对于dex，我们查询最新的各个交易所的trading volume. 然后又AI自己去扩展这些query，比如加时间参数，加 具体的dex参数，可以将query 大幅度低成本的增加。而且这些query 是我们实际中能经常使用的。
- 对于上述query 集合，我们让 AI 自己去设计 API 列表。比如一个复杂的query，AI可能会涉及多个api，怎么去调用，也会顺带解决。
- 除了获取数据以外，data copilot 还定义了几类常用的commandＡＰｉ，比如数据处理变换，预测，可视化。 这几类ａｐｉ的使用，实际上大大增加 data copilot的能力。比如想要看 dex各家的占比，直接就能给出数据+ 饼图。
- 上面就是DataCopilot再设计API时候的思路，通过迭代merge等操作优化设计的质量，我们认为，我们这些api的涉及就是面向AI的API，然后AI可以很好的利用他们解决query的问题。
- 有设计之后，AI 可以利用底层API，做具体的代码实现。
- 总之，在大模型时代，依赖大规模人力的设计，肯定是错误的，不是AI native的设计。
Data Copilot 调用API的思路。
- 首先是对query 识别成意图，而不是直接输出API
- 然后通过意图转化成具体API的调度。这个调度过程可以看到是非常的复杂，比如api1-....api5. 依赖关系甚至可以是并行的。这一步的调度，实际是有gpt完成，可以看到整个推理能力还是比较强的。 从论文给出demo来看，效果还是比较优秀，就是不知道再具体的生产应用上效果如何。
核心的依赖
- 可以看到依赖gpt等大模型对领域知识的理解，论文给出的是金融数据场景，gpt4本身有比较多的知识，效果比较好。
- 另外一篇论文对data copilot场景进行微调的，也就是更好的理解api的业务领域，然后微调，可以更加出色的设计和规划api的调用。 微调的数据集使用的是self-instruct的，基本上都是自己生产微调数据，人工校验。这是大概的思路。
- 最后附上两篇论文：
Data-Copilot Bridging Billions of Data and Humans
Gorilla: Large Language Model Connected with Massive APIs
其他要解决的问题？
- 多个领域的API，整合到一个应用中，是否可以多个微调的模型来处理？
- API 数量太大的时候，doc无法放入prompt中，如何通过预先recall等方式来构建整个pipeline？
- AI 可以设计大量的API，实现依赖底层的source，实现代码的质量和正确性如何验证？
网友评论