首页 文章 精选 留言 我的

精选列表

搜索[key]，共10010篇文章
优秀的个人博客,低调大师

tair 淘宝的分布式key/value存储系统

类redis，项目地址： http://tair.taobao.org/ 或 http://code.taobao.org/p/tair/wiki/index/ 。 与redis类比，摘自互联网。 redis集群中，想借用缓存资源必须得指明redis服务器地址去要。这就增加了程序的维护复杂度。因为redis服务器很可能是需要频繁变动的。 所以人家淘宝就想啊，为什么不能像操作分布式数据库或者hadoop那样。增加一个中央节点，让他去代理所有事情。 所以人家就开发了这个tair。程序只要跟tair中心节点交互就OK了。
2016-09-03
优秀的个人博客,低调大师

《Spring AI 2.0实战》第21招 模型切换不是改个Key

## 01、痛点 我是老李。上周半夜，运维群里突然弹出一条告警：订单分类服务的重试次数在十分钟内翻了五倍。我爬起来一看，是白天同事把默认模型从 A 换成了 B，只改了一个配置项，代码一行没动。原因很简单：B 模型最近降价，老板说能省 40% 推理成本。结果呢？分类正确率从 96.3% 掉到 81.7%，工具调用里 JSON 参数缺字段的比例从 0.8% 涨到 7.4%，RAG 回答的引用准确率也掉了 12 个点。最扎心的是，这些问题在测试环境全绿，因为测试集只有 20 条，而且没有一条覆盖到 B 模型容易犯错的金融术语。 这就是我今天想聊的事：Spring AI 一直强调模型可移植性，但它解决的是代码接口一致，不是模型行为一致。代码不改，绝不等同于可以无测试切模型。尤其现在各家模型价格战，切换变得像改数据库连接串一样随意，事故也越来越常见。为什么现在要讲？因为 Spring AI 2.0 的升级让底层实现更容易换，但也更容易让人产生“随便换”的错觉。 ## 02、是什么 先厘清概念。Spring AI 的 Model Portability 主要做一件事：用 ChatClient、ChatModel 这样的统一抽象，把不同模型提供方的接口差异藏起来。你写 chatClient.prompt().call().content()，不用关心底层是 OpenAI、Azure、Gemini，还是国内几家厂商。这是代码层的可移植性。 但模型可移植性至少有两层。第一层是接口可移植：你的 Java 代码编译、运行、返回类型都一致。第二层是行为可移植：同一个输入，不同模型输出的业务结果是否一致。Spring AI 可以保证第一层，保证不了第二层。 不同 Provider 的差异真实存在，而且不小。Structured Output 上，有的模型原生支持 JSON Schema，有的只支持正则或函数调用模拟，有的在长字段里会截断。Tool Calling 上，有的模型严格输出工具名和参数，有的会把工具结果当成新 prompt 反复调用，有的参数顺序不稳定。多模态上，有的支持图片、音频，有的只支持图片 URL，有的对 base64 大小限制非常狠。Thinking 能力上，有的模型能展示中间推理，有的则是黑盒，推理深度和耗时不透明。Context 窗口从 8K 到 1M 都有，但长上下文不等于长记忆，中间丢失信息很常见。价格和 Rate Limit 更不用说，限流策略直接影响高峰期重试和超时设计。 Spring AI 2.0 的升级记录也印证了这一点：底层 Provider 实现可以切换到官方 Java SDK，同时尽量保持 ChatClient/ChatModel API 不变。听起来很美好，但它恰恰说明，抽象层下面的真实行为会变。官方 SDK 更新节奏、网络链路、默认参数、重试策略，都可能随着切换而改变。API 没变，不代表模型行为没变。 ## 03、为什么 理论上，Portable API 解决的是“代码长什么样”，不是“模型做成什么样”。同一个分类任务，你给两个模型相同的系统消息和用户消息，A 模型可能输出“正面/负面/中性”，B 模型可能输出“正面/负面”，把中性归到负面，或者输出小写、带标点、带解释。你的解析代码如果是容错的，可能不会崩，但业务准确率已经变了。 更隐蔽的是工具调用。统一接口下，你只看到模型返回了一个 ToolCall 对象。但不同模型对工具描述的遵循程度不同。有的模型看到十个工具，能稳定选对；有的模型只要工具描述稍微长一点，就会漏参数。结构化输出也一样，你给了 JSON Schema，A 模型能严格对齐，B 模型可能偶尔多一个字段或少一个 required 字段。这些问题，编译器发现不了，单元测试也未必覆盖。 这就是为什么“代码无需修改”会带来一个危险推论：“代码没改，所以模型可以无缝替换”。实际上，接口抽象把切换成本从“写适配代码”转移到了“验证行为差异”。很多人以为成本消失了，其实只是换了个位置。如果没有验证手段，这个成本会以线上事故的形式爆发出来。 所以问题不是 Spring AI 做得不好，而是它只解决了前半程。统一 API 像统一的插座标准，你插上不同电器能通电，但电器的功率、噪音、耗电量、安全性完全不一样。把电器插上就认为所有电器都一样，显然是危险的。 ## 04、架构 要理解怎么补上后半程，得看整体架构。我一般把它分成四层： 第一层是应用层，也就是你的业务代码：订单分类、客服问答、报表摘要等。它只依赖 ChatClient 和业务领域对象。 第二层是 Spring AI 抽象层，包含 ChatModel、ChatClient、ToolCall、StructuredOutputConverter 这些接口。这一层让你用统一方式编排对话、注册工具、解析结构化结果。 第三层是 Provider 适配层，现在 Spring AI 2.0 可以基于官方 Java SDK 实现。每个 Provider 有自己的连接、鉴权、重试、参数映射。 第四层是模型服务本身，也就是真正执行推理的地方。上下文窗口、推理深度、工具调用实现、结构化输出能力、限流和计费都在这一层。 在这个架构里，Eval Gate 应该放在第二层和第三层之间，或者说放在发布流水线里，作为切换模型的前置关卡。它不是应用代码的一部分，而是工程保障设施。你可以把每一次模型更换理解成一次“行为发布”，而不是一次“配置变更”。 数据流上，评估系统从真实业务和回归集里抽样本，生成标准化请求，同时发给当前模型和候选模型，然后对比输出。判断维度至少四类：业务正确率、结构契约符合度、工具调用成功率、延迟与 Token 成本。只有候选模型过线，才允许更新配置。 ## 05、实战 说回我上周那个事故。事后我们把模型替换流程改成了自动 Eval Gate。具体做了三个场景的对比，这里把方法分享出来。为了不引起口水，模型名我用 A 和 B 代替。 第一个场景是订单分类。我们从过去三个月真实订单里抽了 2000 条，覆盖金融、餐饮、零售、医疗等 12 个类目，并保留原始人工标注。每条样本只走一次模型，统计正确率、平均延迟、单条平均 Token。结果 A 模型正确率 96.3%，B 模型 81.7%。B 模型在“金融-保险”和“医疗-问诊”两个类目上混淆严重。更麻烦的是，B 模型对生僻类目会输出额外解释，导致解析代码把整段解释吞进去，正确率进一步下降。这个场景直接判定 B 模型不通过。 第二个场景是 RAG 问答。我们准备了一个 220 条问题的知识库问答集，答案必须引用知识库片段。测量三个指标：答案正确性、引用准确率、拒答能力。所谓拒答能力，就是当知识库没有相关内容时，模型应该说不知道，而不是编。A 模型引用准确率 93.5%，正确性 91.2%，拒答率 88.6%。B 模型引用准确率 81.0%，正确性 84.3%，拒答率 62.4%。B 模型特别喜欢在找不到依据时补一段“根据一般经验……”，这在客服场景是致命的。这个场景 B 模型也没过。 第三个场景是工具调用。我们注册了六个工具：查订单、查库存、退换货、优惠券、物流轨迹、发票。评估样本 500 条，每条有预期的工具名和参数。统计工具选择准确率、参数完整率、失败重试率。A 模型工具选择准确率 97.8%，参数完整率 96.1%，失败重试率 1.2%。B 模型工具选择准确率 89.6%，参数完整率 85.3%，失败重试率 8.7%。B 模型经常把“优惠券”和“退换货”搞混，参数里常见的手机号和订单号有时会漏一个。延迟上看，B 模型平均低 15%，Token 也略低，但这些优势完全被错误率吞掉。 最后我们把三个场景的指标加权，设置红线：正确类指标不得低于 A 模型 3 个百分点，工具成功率不得低于 2 个百分点，延迟和 Token 可以有 15% 的浮动。B 模型在多个红线外，自动 Eval Gate 直接拒绝发布。这个报告自动生成，发到群里，没人能靠“我感觉差不多”绕过。 ## 06、洞见 经历这件事，我越来越确信：真正的模型可移植性，需要 API Abstraction + Eval，而不只是统一接口。统一接口只是把“能不能跑”的问题解决了，真正难的是“跑得好不好”。一个只保证类型安全的抽象，无法覆盖业务语义。 模型可移植不是配置项，而是工程能力。什么叫工程能力？就是你能回答：换一个模型后，正确率会掉多少？工具调用会不会崩？延迟会增加多少？成本能不能覆盖错误率上升带来的损失？如果没有自动评估，这些问题只能靠线上试，试错的代价就是用户流失和售后压力。 更深一层，统一 API 甚至有可能让人低估差异。因为编译通过、运行不报错、返回类型正确，人就会产生“可控”的错觉。实际上，模型行为差异发生在语义层，而不是语法层。语法层的问题最好解决，语义层的问题最难发现，也最伤业务。 所以 API Abstraction 的价值不是让你随便换模型，而是让你把换模型的决策权从“代码能不能接上”升级为“数据能不能过线”。Eval 也不是简单跑几个样例，而是可重复、可量化、可回溯的质量关卡。没有 Eval 的抽象是盲目的，没有抽象的 Eval 是昂贵的。两者合在一起，才构成真正的可移植性。 ## 07、行动 如果你现在正在用 Spring AI，或者准备用，我建议把下面这套动作落到流水线里。 第一步，建立基线数据集。不要用网上公开的通用评测集，那个只能证明模型不笨，不能证明你的业务不坏。基线数据必须来自真实业务：真实订单、真实客服对话、真实文档、真实工具调用。数量不用贪多，每个场景 300 到 1000 条，但类目分布要贴合线上。 第二步，定义指标和阈值。至少四类：业务正确率、结构契约符合度、工具调用成功率、延迟与 Token。给每类设红线。例如正确类指标下滑超过 3 个百分点直接拒绝，工具成功率下滑超过 2 个百分点拒绝，延迟上涨超过 20% 需要人工复核。红线要写进配置文件，不能临时拍脑袋。 第三步，把评估做成自动任务。候选模型配置一提交，流水线就自动拉取基线数据集，批量请求候选模型和基准模型，生成对比报告。报告里要有每类样本的混淆矩阵、错误样例、延迟分布、Token 分布。不能只看一个总分，要能下钻到具体错误。 第四步，设置 Eval Gate。评估通过才能发布配置，评估不通过自动阻断。这里强调“自动”，是因为人很容易被价格和 PPT 数据说服。自动门禁不看人情，只看数据。 第五步，线上灰度。即使评估通过，也建议先切 5% 流量，观察错误率、重试率、客诉关键词。灰度 24 小时无异常再全量。模型切换不是配置变更，是行为发布，要像发新版本一样谨慎。 这套动作不需要很复杂的平台。一个定时任务、一组脚本、一个报告生成器就能跑起来。关键是数据集和红线要持续维护，业务变了，评估集也要跟着变。 ## 08、小结 回到最开始的问题：为什么“代码无需修改”不代表“可以无测试切模型”？因为代码不变只能证明接口兼容，不能证明行为兼容。Spring AI 给了你一个很好的抽象底座，Spring AI 2.0 又让你能比较方便地替换底层实现，但抽象底座本身不负责业务正确性。 模型可移植性的真正公式是：API Abstraction + Eval Gate。前者保证能接，后者保证能切。缺了前者，你会被适配代码拖垮；缺了后者，你会被线上事故教育。现在模型更新速度越来越快，价格越来越低，切模型会变成常态。谁能把评估做成自动关卡，谁才能享受到模型升级的红利，而不是成为模型差异的受害者。 ## 09、链接与概念说明 这里解释几个文中出现的概念，方便你进一步查阅。 Spring AI：Spring 官方提供的面向 Java 的 AI 应用开发框架，提供 ChatClient、ChatModel、ToolCall、结构化输出等抽象。官方地址：https://spring.io/projects/spring-ai ChatClient / ChatModel：Spring AI 中统一的对话调用入口。ChatModel 是底层模型接口，ChatClient 是更面向业务的流式 API，包含对话、函数调用、结构化输出等能力。 Model Portability：模型可移植性。在 Spring AI 语境下，通常指通过统一接口切换不同模型提供方而不改业务代码。但本文强调，它只覆盖接口层，不覆盖行为层。 Structured Output：结构化输出，即要求模型按给定的 JSON Schema、正则或枚举约束返回结果，而不是自由文本。不同提供方对该能力的支持程度和实现方式不同。 Tool Calling：工具调用，也称函数调用。模型根据对话上下文决定是否调用外部工具，并返回结构化的工具名和参数。不同模型对工具选择的准确性和参数完整率差异较大。 Eval Gate：评估门禁。在 CI/CD 流水线中，自动运行评估集并判断候选模型是否达到发布标准。红线和指标包括正确率、工具成功率、结构符合度、延迟、Token 等。通过才允许切换。 最后提醒一句：模型切换的风险从来不在于代码跑不起来，而在于业务结果悄悄变差。把评估做在前面，才能踏实享受模型进步的好处。
2026-09-03
优秀的个人博客,低调大师

阿里云 11.12 故障原因曝光：访问密钥服务 (Access Key) 异常

针对阿里云11.12的重大服务故障， 该公司发给客户的一份「官方故障报告」昨天在网上被广泛流传。 事件回顾：阿里云严重故障，全线产品受影响（已恢复） 影响范围 1、OSS、OTS、SLS、MNS 等产品的部分服务受到影响，大部分产品如 ECS、RDS、网络等运行不受影响。 2、云产品控制台、管控 API 等功能受到影响。 时间 2023年11月12日17:39～19.20，故障时间为 1 小时 41 分。 问题概况 2023 年 11月 12 日 17:39 起，阿里云云产品控制台访问及管控 API调用出现异常、部分云产品服务访问异常，工程师排查故障原因与访问密钥服务 (AK)异常有关。工程师修订白名单版本后，采取分批重启 AK 服务的措施，于 18:35 开始陆续恢复，19:20 绝大部分 Region 产品控制台和管控 API 恢复。 处理过程 17:39：阿里云云产品控制台访问及管控 API 调用出现异常。 17:50：工程师确认故障是 AK 服务异常导致，影响云产品控制台、管控 API 调用异常，以及依赖 AK 服务的云产品服务运行异常。 18:01：工程师定位到根因。 18:07：开始执行恢复措施，包括修订白名单版本、重启 AK 服务。 18:35：杭州等 Region 开始恢复正常。 19:20：绝大部分 Region 的云产品控制台和管控 API 调用恢复正常。 原因 访问密钥服务 (AK）在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控 API 服务出现异常，同时部分依赖 AK 服务的产品因不完整的白名单出现部分服务运行异常。 改进措施 1、增加 AK 服务白名单生成结果的校验及告警拦截能力。 2、增加 AK 服务白名单更新的灰度验证逻辑，提前发现异常。 3、增加 AK 服务白名单的快速恢复能力。 4、加强云产品侧的联动恢复能力。
2023-11-16

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册