收益：
- 能够建立安全的云LLM架构，该架构不会将API密钥保留在客户端，而是通过后端代理
- 能够编写强大的集成，以提高流式传输的感知速度，并温和地处理超时、网络错误和速度限制等情况
- 能够通过缩短发送的令牌来降低成本，并在个人数据进入云端之前质疑其必要性
设备上的人工智能功能强大但有限。当您想在应用程序中添加真正的“智能聊天助手”、长文本摘要或复杂的创意制作时，您需要的模型太大而无法安装在手机上。这就是云 AI 发挥作用的地方：您的应用程序通过 API（应用程序编程接口 - 两个软件相互发送和接收数据的标准接口）连接到大型语言模型 (LLM)。在本单元中，我们将学习如何以安全、快速且具有成本意识的方式将云法学硕士集成到移动应用程序中。重点是安全性：错误安装的 LLM 集成可能会泄露您的 API 密钥并导致价值数千英镑的账单。
架构的黄金法则：将钥匙留在客户端
云人工智能集成中可能犯的最危险的错误是将API密钥（授权使用服务的秘密密码）直接嵌入到移动应用程序代码中。移动应用程序被下载到用户的设备上，并且可以通过逆向工程读取代码 - 解析编译的应用程序并查看其中的内容。如果您的密钥位于应用程序内，则有人可以提取它并从您的帐户发出无限的请求。
正确的架构是这样的：移动应用发送请求到你自己的后端服务器（你控制的代理服务器）；密钥仅驻留在服务器上；服务器转到 LLM 服务并将响应返回给应用程序。该中间件还提供速度上限、滥用预防和成本控制。
方法
关键在哪里
安全性
关键在于应用程序（FALSE）
在客户端、公共
它泄漏了，账单爆炸了
关键在后端（TRUE）
在服务器上，隐藏
安全可控
注意：当您要求 AI 进行云 LLM 集成时，它可能会生成一个示例，将密钥直接写入应用程序代码中，以方便您使用。永远不要把这个直播。请务必在提示中包含“API 密钥不应位于客户端，请通过后端代理”这句话。
流媒体：提高感知速度
LLM 的答案可能很长，需要几秒钟才能完整生成。让用户在空白屏幕上等待是一种糟糕的体验。解决方案是流式传输——逐字显示生成的答案。用户监控文本的拼写，如 ChatGPT 中那样；这极大地提高了感知速度和流畅度。移动设备上的流程意味着将片段（令牌 - 模型生成的文本片段）从服务器添加到界面。打印集成到 AI 时明确请求流程。
提示：在流响应中添加“暂停”按钮。当用户得到他想要的答案时应该能够停止生产；这既可以改善体验，又可以通过减少不必要的代币生成来降低成本。在冗长的答案中，用户可能已经找到了答案。
成本、延迟和错误管理
Cloud LLM 每次请求都会产生金钱成本（每个令牌的费用）和时间成本（延迟）。三个学科是必不可少的。 Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible.延迟：使用流式传输，设置超时，如果网络速度慢则通知用户。错误：网络中断，服务可能返回429（请求过多）或500（服务器错误）；温柔地处理每一个，不要让应用程序崩溃。此外，LLM有时会给出无意义或不正确（幻觉）的答案；在关键区域添加一层对答案的验证。
三个迷你箱子
案例 1 — 密钥泄露。一家初创公司将 OpenAI 密钥直接嵌入到其 React Native 应用程序中，以便快速退出。该应用程序发布三周后，密钥被逆向工程，一夜之间就获得了价值 2,400 美元的使用量。该团队不得不撤销密钥并设置后端代理。教训：为了方便而走的捷径变成了最昂贵的路线。
情况 2 — 丢失率随着流量的增加而减少。某教育应用首次推出无直播问答功能；用户在闲置等待 6 秒后退出。添加流量后，第一个词在 0.8 秒内开始出现，放弃率从 48% 下降到 12%。相同的型号，相同的速度——只是表现形式不同。
案例 3——成本控制。一个应用程序将整个聊天历史记录与每条用户消息一起发送给模型；在长时间的对话中，单个请求达到 8,000 个令牌，导致成本增加。通过仅发送最后几条消息和摘要，团队将每个请求的代币减少了 70%，将每月的账单减少了三分之一。教训：衡量你发送的内容。
弱提示/强提示
弱提示：“将像 ChatGPT 这样的聊天添加到我的应用程序中。”
强大的提示：“在我的 iOS/Swift 应用程序中添加一个聊天助手。 架构：应用程序向我自己的后端发送请求，LLM API 密钥不在客户端，它通过代理。 - 响应是流式传输的，逐字显示 - “停止”按钮中断生产 - 优雅地处理超时、网络错误、429 和 500 情况 - 缩短聊天记录：发送最后 6 条消息 + 摘要（成本控制）先解释架构图，然后分别给出客户端和代理代码。”
可复制模板
安全架构模板：“设计云 LLM 集成到我的[平台]应用程序中。规则：API 密钥仅在后端。客户端 -> 我的代理 -> LLM。在代理中：身份验证、每用户速率限制、请求日志记录。分别列出客户端和代理职责，然后导出代码。”
流式传输模板：“向此聊天屏幕添加流式响应：- 在消息到达时将片段添加到消息气泡中- 在键入时显示光标/动画- 使用“停止”按钮取消流式传输- 保留部分文本，并在流式传输结束时警告是否出现错误[现有代码]”
成本延迟模板：“降低 LLM 集成中的成本和延迟：- 如何减少发送的令牌（历史缩写、摘要）？- 在这种情况下，更小/更便宜的模型就足够了？- 建议超时和重试策略[代码]”
容错模板：“使此 LLM 呼叫具有弹性：- 无网络、超时、429（速率限制）、500（服务器）的单独行为-向用户发出非技术性、礼貌的消息-针对关键回复中幻觉风险的验证说明[代码]”
常见错误
- 将 API 密钥嵌入到应用程序中。最昂贵且最常见的安全漏洞；关键肯定是在后端。
- Not using flow.让用户等待较长的答案将会赶走用户。
- 每次请求时都会发送整个聊天记录。它使代币成本和延迟成倍增加。
- 绕过错误条件。如果 429/500/超时未得到解决，应用程序将崩溃或冻结。
- 毫无疑问地认为 LLM 答案是正确的。幻觉是真实的；在关键区域添加验证层。
- 将用户数据发送给不必要的 LLM。询问个人数据在进入云端之前是否需要或应该被屏蔽。
总之
Cloud LLM 为移动设备带来了不适合设备的强大功能，但需要安全性和成本控制。黄金法则：API 密钥永远不会在客户端上，它会通过后端代理。心流极大地提高了感知速度和保留率；由“停止”按钮支持。成本是通过缩短发送的令牌来确定的；通过优雅地处理所有错误情况来实现弹性。 LLM 的答案可能包含幻觉；在关键领域，验证至关重要，并且在将个人数据发送到云端之前会对其进行审查。
应用任务
使用“安全架构模板”向 AI 请求客户端 + 后端代理设计，以实现“文本摘要”或“聊天”功能。验证 API 密钥仅驻留在生成的设计的后端中。然后提取至少两种方法来减少使用“成本延迟模式”发送的令牌，并编写要向用户显示的错误情况（例如 429）的礼貌消息。
清单
- [ ] 我验证了 API 密钥位于后端而不是客户端
- [ ] 我制作了响应流并添加了“暂停”按钮
- [ ] 我处理了超时、网络错误、429和500的情况
- [ ] 我用过去的缩写/摘要减少了提交的令牌
- [ ] 我考虑过验证法学硕士答案中的幻觉风险
- [ ] 在进入云端之前我检查了个人数据的必要性/屏蔽