仅仅因为大语言模型（LLMs）能流利地使用自然语言，并不意味着我们应该总是用自然语言和它们交流。
当涉及到重要的流程时，人类之间自己也不会用自然语言来沟通。经验表明，缺乏结构，流程就无法扩展。表格这种东西在计算机出现之前就已经存在很久了。
大语言模型在自然语言方面的流畅性，对于交流和弥合许多集成问题中的模糊地带很有价值 。但同时，它也可能是一种干扰 ，不应该让我们在设计基于 LLM 的系统时变得懒惰。
澳大利亚联邦银行（Commonwealth Bank）的布莱尔·哈德森（Blair Hudson）提出，第一波生成式 AI 的应用之所以部分失败，是因为它过度依赖于"聊天"（Chat）这种形式 。尽管 ChatGPT 是历史上增长最快的消费者应用，但它为大多数企业对底层技术的应用指明了错误的方向。
世界各地的团队之所以构建聊天界面，是因为它们通用且能快速原型设计。其中少数界面最终转化成了产品。
在我看来，聊天界面之所以使应用采用率停滞不前，是因为工作本身并不是在聊天界面中完成的 。你不能通过一个聊天窗口来运营一家医院、管理一家零售店，或是管理一条供应链。对于大多数工作而言， "聊天"是一种错误的抽象方式。它确实释放了某些能力，但真正的生产力需要更多东西。
错误的界面无疑是一个因素。但更重要的是缺乏结构。
人类不会通过文字来运营医院。他们会从多个来源获取和更新结构化信息 ，因为他们知道结构能使流程更安全、更可预测。他们不希望监测器显示"金姆的血压一天大部分时间都稳定，除了上午晚些时候有个峰值"------他们希望能够查看图表 并在发生危机时收到警报 。医生在撰写病历时会包含自然语言，但会尽可能多地使用结构化数据：每种药物的毫克数；体温、血氧饱和度和其他读数。即使是像病人情绪这样的主观信息，也通常用结构化的问卷和量表来表达，以便于比较。
自然语言的成本
虽然诱人，但过度依赖自然语言 的生成式 AI 应用会带来高昂的成本。它能在短期内快速产生令人印象深刻的结果，但以牺牲未来的问题为代价。
自然语言是不透明的（opaque）。 很难对其应用工具。搜索是不精确的，即使使用了昂贵的向量嵌入（vector embeddings）也是如此。LLM 的理解能力并非完全可信 ，并且会增加更大的延迟和成本 。构建精确 RAG（检索增强生成）系统的难度就证明了这些问题。此外，当所有信息都是自然语言时，在代码中执行某些步骤也很困难------而我们肯定希望这样做，因为执行代码永远比使用 LLM 更便宜、更具确定性。
自然语言也是模糊的（ambiguous） ------这也是编程语言存在的原因之一。
传统的软件产物，如对象（objects）或数据库行（database rows） ，在解决许多对业务应用很重要的核心问题上，具有远超自然语言的优势，例如：
- 搜索： 如果我们知道一个相关的 ID，我们就能确定找到所需信息，或确定我们没有它（后者尤为重要）。如果我们有结构化数据，我们可以高效地查询它，并利用适当数据库的丰富能力来考虑关系。
- 变更追踪： 我们引入的结构越多，观察变更的成本就越低，准确性就越高。例如，我们可以检测对象图中的变化，或使用触发器来观察数据库中细粒度的变化。
- 安全、选择性共享： 我们可以确定模型中哪些部分是安全的，可以与信任度较低的各方共享。
在构建生成式 AI 应用时，当可以采用结构化方式时却退回到使用自然语言，是一种懒惰的选择。它节省了前期的时间，但却为将来埋下了问题。
好的，那么需要什么样的结构呢？
如果我们确实需要结构，应该从哪里寻找呢？
大语言模型（LLMs）并不太关心我们使用哪种格式。基于大量的训练曝光，它们可以轻松理解 JSON、XML 和其他常见格式。
更有意思的问题不在于表现形式 ，而在于我们如何填充这些结构。
对于商业应用而言，答案是显而易见的，但在许多关于生成式 AI 的文章中却奇怪地被忽视了 ：在可能的情况下，我们应该使用那些已经存在并反映领域理解的结构。
领域集成（Domain integration）是至关重要的。在可能的情况下，我们应该利用 LLM 来说出我们领域（Domain）的语言，而不是自然语言。
许多最有价值的生成式 AI 应用将从现有的业务应用中成长出来 ，而非完全是全新的。这些应用将借鉴现有的领域模型和基础设施，因此会更加健壮和实用。
JVM 的优势
这就是企业 Java 生态系统大放异彩的地方。几十年来，Java 开发者一直擅长于生成式 AI 应用所需的核心能力：领域建模（domain modeling）、类型安全（type safety）和结构化数据处理。
虽然 Python 框架与现有企业系统相距甚远 ，并倾向于将所有数据视为字符串（strings）和字典（dicts），迫使你用脆弱的代码处理 LLM 输出；但基于 JVM 的方法则可以利用：
- 强类型（Strong typing）： 你的 LLM 输出可以直接反序列化为领域对象。
- 现有领域模型： Spring Data 实体、JPA 模型------数十年的领域知识已经通过代码捕获。
- Bean Validation (JSR 380)： 对 LLM 输出进行结构化验证，而非凭空猜测。
- 久经考验的基础设施： 你现有的 Spring Boot 配置、持久层和企业集成。
不要偷懒
如果你正在构建任何任务关键型 的生成式 AI 应用，请不要偷懒。像你在任何应用中一样对领域进行建模 。更好的是，使用现有的领域模型 。引入使企业系统可靠的工程规范。这样一来，你的应用将更安全、成本更低、更可预测。
如果你正在使用 JVM ，你已经处于领先地位 。你拥有工具、模式、基础设施，以及一个丰富的代理框架 Embabel。不要仅仅因为 LLM 擅长英语就放弃你的优势。