AI大模型企业业务应用模式
这里，我重点讲述深蓝色部分的两种模式：第一个是翻译模式，第二个是 Agent 模式，我认为主要分为这两种典型的应用模式。其中，翻译模式最容易取得成效，因为它相对简单；而智能体模式则较为复杂。
翻译模式
先谈谈翻译模式。 在公司内部，将所有翻译类模式统称为 AI 领域的“低垂果实”，这类模式相对容易实现。这一轮的大型语言模型背后的算法是 Transformer。Transformer 最早是 Google 为了翻译任务而开发，在不停做翻译的过程中衍生出了 Transformer 算法。随后，预训练模型如 BERT 也大量应用于翻译领域。所以，大模型的原理 Transformer 特别擅长做翻译。
翻译又可以分为狭义翻译和广义翻译。狭义翻译指的是中译英、英译中等语言之间的转换。而广义翻译则涵盖更广泛的形式，比如：自然语音转成文本，再转成语音；自然语言转成 SQL 语言；自然语言转成 Java 语言；甚至让一篇论文用自然语言“翻译”成中学生能听懂的表述，这些都属于广义翻译范畴。无论是狭义翻译还是广义翻译，Transformer 都特别擅长，因此这是最容易出结果的地方。
但这里有一个坑： 虽然（图中）左边的翻译能力已经具备，但如果右边原有的系统还没准备好（not ready），就会出现问题。
以 Chat BI 来说，为什么 Chat BI 在企业里没什么成功的案例呢？其实很大一部分原因在于，Chat BI 的逻辑无外乎就是：用自然语言翻译成 SQL，然后在后台的数据库或大数据系统里执行，再把执行结果取出来，再翻译成自然语言返回给人。它的实质，就是自然语言 → SQL → 执行结果 → 自然语言，这本质上还是一种翻译。
但我们会发现一个很有意思的问题：很多企业说要上 Chat BI，但如果原本数据库和里面的业务逻辑、数据口径积累不足，甚至连人都写不出对应的 SQL 来，那自然语言也一样翻译不出来。因为后台本身没有可执行的基础。所以作者认为，企业里绝大部分在 Chat BI 上踩的坑，都来自于一开始就想做一个过于“宽”的东西。但是做了这个翻译之后，如果原来的系统 API 没准备好，数据没准备好，甚至连原来的人都无法执行这些操作，那自然语言翻译也没法落地。这就是最大的误区。
因此我们在内部的逻辑是：要先Identify 原系统具备哪些能力。比如，如果你原来的 ODPS、数据库和数据中台本身已经有 BI 和运营，能够在某个领域里不断取数、用 SQL 分析数据，而且业务场景也很丰富，那么，那些高频的 SQL 语句才是真正值得作为翻译目标的部分，而不是盲目地去做一个 Chat BI。
所以很关键的是要分成两个部分 ：一部分是翻译，一部分是原来系统的语言处理能力。我习惯这么来形容：原来的系统就是“蛋糕坯”，大模型翻译就是上面的“樱桃”。如果你现有的蛋糕坯是 ready 的，我放一个樱桃上去，你就可以吃樱桃蛋糕了。但是如果原来的蛋糕坯都没有，你让我做一个樱桃蛋糕，那是做不出来的。
所以，这里非常关键的一点就是：你要能够识别出原来的蛋糕坯是不是 ready ，然后在上面放上你的樱桃，而不是直接拿一个樱桃就装作是樱桃蛋糕。这个地方往往就是个误区。
Agent 模式
再说 Agent 应用模式。大家可以注意这样一句话：所有的 Agent 应用模式都是始于用户意图，终于意图满足。如果你不是从用户意图出发，最后又不是以是否满足客户意图来作为度量标准去看待你的智能体，那一定会失败，没有任何成功的可能性。这是我发现团队甚至整个业界，最容易出现的问题。因此我们引出了一个方法，这是我在内部做智能体时，一定要去践行的方法。
第一件事情，要找到这个领域的“意图空间”。 当一个客户在智能体里和你交互时，他一定是带着意图的。那么这些意图都有哪些？比如客服场景里，客户会提出各种咨询问题，这些问题本质上就是一个空间、集合。所以，第一步就是要搞清楚这个集合的 边界和完整性。如果你不知道它的完整性，就无法去度量。只有在建立了完整的意图空间之后，才能继续往下做。
所以第一件事要建立意图空间。然后，当清楚地知道了意图空间，就要基于这个意图空间来准备 知识工程。也就是说，你的知识、文档是否完备？API 和结构化数据是否具备？能否真正满足客户的这些意图？我认为这是最基础的必要条件。
再者，有了知识、意图空间，接下来才能带着意图去做评测。 因为你既知道用户的意图，也掌握了知识，这样才能真正开展工作。如果意图不清楚、知识不具备，那其实就是“空转”。
我们的经验是：在客服场景里构建意图空间，从原来就在满足意图的领域出发，从 工单 里去分析和构建意图空间。有了意图空间之后，就可以对意图进行分类。分类完成后，再根据不同类别去检查和补全知识，做好知识工程。这样，当 意图空间 和 知识空间 都建立好了，才有可能开展评测，也才知道如何去度量你的 Agent。只有具备了度量能力，才有可能进一步做工程和算法迭代，这个是原理决定的。这也是我们在内部做智能体的一个必修课。
所以我简单总结一下两个模式： 翻译模式是樱桃，一定要先找到原来的蛋糕坯在哪里，再把樱桃放上去。如果蛋糕坯不 ready，只放个樱桃一定会失败。而 Agent 模式的关键则是：始于用户意图，终于意图满足。 这是一系列完整的逻辑方法。
......
Chat BI 本质上也是 Agent 模式。除了将自然语言翻译成 SQL 之外，SQL 执行完后，结果需要用自然语言翻译回去。但关键在于底层的数据中台，以及原有的数据治理是否完善。如果原有系统（蛋糕坯）不够完善，就无法实现良好的 ChatBI 效果。ChatBI 本身只是一种技术手段，最终一定要识别出，对应领域是否已经有成熟的数据体系和成熟的数据分析，只有在此基础上再加上 AI，才能产生魔法般的效果。
Result as a Service（RaaS）