企业AI访问控制：将策略转化为运行时强制
API密钥为软件提供身份验证。策略对象决定该软件被允许执行的操作。 本系列上一篇文章 以会议室中的一个问题结尾：究竟是谁决定我们可以这样做？当时的论点是，答案必须存在于网关能够强制实施任何策略之前，而网关的职责就是让这个答案可重复执行。 这篇文章要探讨的是，当一个答案不再只是一个决定，而是成为一个对
在 DigitalOcean Serverless Inference 上使用 OpenCode：将 DO 托管的模型用作带推理路由器的智能体编码后端
像Claude Opus 4.8这样的前沿模型可以驱动跨语言的智能体编程，从Python到C++再到GDScript；但在生产规模下，它们的每token成本会迅速累积。DigitalOcean的推理路由器（Inference Router）直接解决了这个问题：它将常规任务路由给较小的开源模型，仅在任
产品实验中的双重稳健估计：当两个模型在LLM应用中均出错时
你的AI产品在六个月前推出了一个代理模式选择加入功能。你进行了倾向性分析，根据参与度层级和查询置信度进行了调整，并报告了任务完成率干净利落地提升了8个百分点。这个数字进入了季度业务回顾，大家都很满意。 不可避免地，一位严谨的数据科学家会提出一个令人不安的问题。你有多大把握倾向性模型捕获了所有混杂因素
租户感知：如何在不依赖聊天JSON的情况下审核图像生成的文本提示词
简要回答：在生成之前对完整图像请求进行分类，返回一个小的JSON决策，并将分类器和图像调用附加到同一个租户账本上。有用的设计选择是成本边界，而不是特定的审核端点。 对于物流产品来说，这个账本很重要。承运商、仓库运营方和内部支持团队可能都通过同一个图像功能发送提示词，但他们的审核率和提示词大小各不相同
为什么你的LLM账单是预期的3倍：生产环境推理系列
从业者关于隐藏推理成本乘数的论述，附带 DigitalOcean Serverless Inference 的实测数据。跨提供商的模式普遍适用。以下DO特有数字来自在 inference.do-ai.run 上记录的API运行，而非营销宣传。 差距是结构性的，而非账单错误 你在生产环境中的LLM账单
规模化产品实验：Airbnb、Netflix、Lyft和Uber如何对基于LLM的AI功能进行因果推断
基于LLM的AI功能的因果推断不再是理论问题。Airbnb、Netflix、Lyft和Uber都发布了详细的工程博客文章，精确描述了它们如何衡量产品变更对用户行为的因果影响。 它们提到的技术（双重差分、断点回归、双重稳健估计等）都是标准工具。 有趣的是这些团队如何在规模化生产中落地这些方法：哪些方法
db-semantic-mcp：为AI智能体提供数据库的安全语义地图
AI智能体在理解数据库之前就获得了数据库访问权限。 这个顺序是错误的。 真实的生成数据库很少是不言自明的。重要的表并不总是命名为 orders 。客户表可能被称为 t_bd_customer 。一个字段可能带有业务关键状态码，只有了解其背后的系统才能理解其含义。数据仓库可能将原始操作数据、清洗后的维
AI评估工程：从零开始构建生产级LLM评估平台 [完整手册]
令人印象深刻的演示与值得信赖的系统之间的差距，是用评测来衡量的。 我想从一个正在数百个工程团队中发生的故事开始。 一个团队为法律研究构建了一个RAG应用。他们用40个精心挑选的问题进行测试。答案看起来不错，于是他们向合伙人团队演示。合伙人们印象深刻，他们便将其上线了。 上线三周后，一名律师助理标记了
一夜处理百万文档：端到端批量推理
假设你的对象存储中有一百万张支持工单，而明天早上之前你需要将每一张按问题类型分类并总结成一段话。第一时间想到的显然是通过实时聊天补全API逐个发送，但这是错误的方法。按照标准速率限制，仅请求本身就需要超过一天时间，每个token都要付全价，而且在凌晨三点的一次网络故障就可能让你的脚本半途而废。 本文
为推理用例选择正确的模型：生产环境中的推理系列
一种可重复的推理模型选型方法：基于你自己的数据评估模型，并附上DigitalOcean Serverless的一手成本数据。该方法与云厂商无关；DigitalOcean的特定数据有来源引用。 模型选择使成本相差几个数量级 在GenAI部署中，模型选择——而非基础设施、提示词优化或批处理策略——是影响