大语言模型引领的新API经济
强大语言模型的崛起正在创造一个新的API经济，其中自然语言取代结构化代码成为主要接口。
传统API与LLM API的对比
传统上，API调用会是GET /users/123/orders，你会收到JSON返回，这将返回用户123的订单。API促进了不同软件系统之间的交互。
但如果查询更复杂呢？如果需要与另一个系统交互而不太了解如何调用API呢？如果与系统交互的人是非技术人员，不知道如何调用API呢？
这正是大语言模型发挥作用的地方。LLM可以作为一个通用API，能够解释输入并生成输出。在这种情况下，输入是自然语言查询，输出是API。
这改变了软件的构建方式以及用户与软件的交互方式。本文从两个角度讨论这一方面——开发者应如何构建支持LLM类型API的软件，以及用户如何使用LLM与软件交互。
从代码到自然语言
传统API是确定性的：你发出特定请求并获得已知响应。每次调用传统API时，响应都是相同的。它们可预测、可靠且僵化。但LLM改变了这个等式。
传统API示例：
GET /users/123/orders → JSON → 手动过滤和聚合
LLM API示例： “用户123上个月订购了什么？” → LLM → “用户下了3个订单，总计249美元”
LLM驱动的API访问通过使用自然语言而非结构化语法与系统交互，提供了变革性的转变。与传统API需要理解端点、参数和认证细节不同，LLM解释用户意图并在后台生成正确的API调用。这消除了对技术专业知识的需求，使API访问对非开发者（如分析师或产品经理）可用。
LLM如何改变我们构建和使用API的方式
从结构化代码到非结构化语言的根本转变要求软件生命周期中涉及的每个人都要适应，从构建API的开发者到与之交互的最终用户。
API开发者
开发者现在需要转变，因为这需要新的技能组合。API是契约，应该如此维护。从调用用户端来看，他们希望调用API并期望在参数相同的情况下每次都获得完全相同的结果。随着LLM产生幻觉和依赖概率，维护契约可能变得具有挑战性。
- 创建提示模板以根据用例指导模型行为
- 慢慢将LLM API集成到代码库中
- 理解并非所有API都需要通过LLM API使用
- 优化LLM延迟和令牌使用
- 设置良好的防护措施以防止LLM API被滥用
- 建立故障检测模型以最小化幻觉
- 即使在LLM API中也启用良好的访问管理
这催生了LLMOps，这是一个专注于LLM应用程序生命周期管理的新学科，包括提示监控、A/B测试提示模板以及维护可观察性以进行故障检测和解决。
API用户
这些LLM API的调用者可以感到高兴。由于LLM API正在成为现实，这给了调用者选择调用哪种API的能力。
从调用者的角度来看：
- 确保API适合目的
- 假设错误可能发生
- 确保关键工作通过定义良好的API调用
- 提高AI素养，理解构建输入以获得最佳输出的最佳方式
- 调整自己的软件与LLM API的交互
非技术用户
LLM不仅赋能开发者；它们为其他所有人打开了大门。以前，设计师可能必须使用复杂的用户界面来执行某些操作。内部来说，当按下按钮时，正在调用API来执行操作。但现在，设计师可以简单地提示LLM执行某个操作，甚至指导设计师执行该操作的最佳方式。
对于这类用户，像GET /users/123/orders这样的查询很难理解。语言提供了询问更多内容的机会：“用户123上个月订购了什么，给我一个摘要并与该地区的其他用户进行比较”。这个查询作为一个多面向的问题，直接服务于用户的目的。
语言作为新的API表面
最大的转变不仅仅是技术性的——它是概念性的。
有了LLM，API表面变成了语言。你不仅仅是在编码函数，你是在编写指令。你不仅仅是在设计屏幕，你是在启用交互。你不仅仅是在调用特定的API，你是在提出问题。LLM正在将范式从刚性接口和预定义契约转向更具适应性、对话性和智能的系统。
不仅仅是上述类别需要改变。最大的变化必须是企业如何采用它们。LLM暴露了可以定制的接口和代理。对企业来说，这意味着LLM不仅仅是另一个工具，而是一个可定制和智能的层，可以包裹在现有遗留系统周围。
向使用语言作为API的过渡仅仅是个开始。随着这些系统变得更强大和集成，使用软件与进行对话之间的区别将减少，从根本上重塑我们与技术的关系。将LLM视为API是迈向那个未来的第一个关键步骤。