作者小头像 Lv.2
更多个人资料
99 成长值
0 关注
0 粉丝
+ 关注 私信

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据
个人勋章
TA还没获得勋章~
成长雷达
90
9
0
0
0

个人资料

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据

达成规则

以上满足项可达成此勋章

  • 博客
  • 关注
  • 粉丝
  • 论坛
全部时间
全部时间
最近三天
最近一周
最近一月
  • 全部
  • 暂无专栏分类
Oracle 把语义层塞进 Lakehouse，赌的是 Agent 读不懂你的业务口径
Oracle 在 AI World 2026 上给 Autonomous AI Lakehouse 加了一批功能，其中“全新的业务语义层”排在很前面，同批还有 Iceberg 支持扩展、AI 数据目录和业务模拟工具。语义层不是新概念，但把它放在 Lakehouse 和 Agent 的上下文里，指向的问题变了：Agent 写 SQL 不難，难的是它不知道“活跃用户”在你的公司里到底指 7 天登...
Oracle
作者小头像 yd_295824913 2026-10-30 00:23:53
0
0
0
2026-10-30 00:23:53
0
0
0
契约测试：微服务联调最容易被跳过，也最容易在发布夜爆炸
问题：两个服务由不同团队维护，消费方依赖提供方的某个字段和状态码。单元测试各自都过，集成测试环境不稳定经常跳过，结果提供方一次“看起来无害”的字段重命名，消费方上线后解析失败。契约测试解决什么：消费方定义它期望的请求和响应契约，提供方在 CI 中验证自己是否满足这些契约。契约不是完整 API 文档，只覆盖消费方实际用到的部分。提供方改字段之前，契约测试会先红，而不是等消费方线上报错。落地方式...
微服务
作者小头像 yd_295824913 2026-10-29 00:48:52
3
0
0
2026-10-29 00:48:52
3
0
0
对外 API 的幂等设计，本质上是成本分配问题
“所有写操作都要幂等”已经成为 API 设计的常识，但幂等键放在哪一层、谁负责生成、重试窗口多长，这些决策决定了幂等是真正生效，还是仅仅在文档里存在。一个比较务实的做法是要求调用方在创建、扣款等写操作中传入 Idempotent-Key，服务端用 Redis 的 SETNX 或等价机制锁住这个 key，配合业务唯一约束做双重保障。调用方重试时携带同一个 key，服务端返回首次执行的结果，而不...
API
作者小头像 yd_295824913 2026-10-28 01:29:21
11
0
0
2026-10-28 01:29:21
11
0
0
技术债排优先级：看“利息”，不看“严重程度”
技术债清单很容易变成“什么都很严重”，最后谁声音大谁先修。更可操作的排序维度是“利息”：这笔债每天在消耗多少团队时间、多少事故成本、多少新功能延迟。我会给每笔债估三个值：发生频率、单次影响、增长趋势。频率高、影响中等、还在增长的债，优先级高于频率低但标签“严重”的债。比如一个每次发布都要手动改配置的脚本，单次只花 10 分钟，但每周发布三次、涉及三个人，一个月就是十几个小时，还容易漏改出事故...
作者小头像 yd_295824913 2026-10-27 00:16:10
15
0
0
2026-10-27 00:16:10
15
0
0
Agent 的可靠性瓶颈，在“副作用”而不在“智能”
做 Agent Demo 很容易，做一个敢让它碰生产系统的 Agent 很难。最常见的故障模式不是模型推理错了，而是工具调用产生了不该发生的副作用：超时后自动重试，结果重复下单、重复发消息、重复建工单。模型可以重试，系统不能重复生效。这引出一个被低估的工程原则：任何有副作用的工具都必须支持幂等。支付、发消息、写数据库、创建工单，这些操作需要幂等键，让“重试”在语义上等价于“只执行一次”。Ag...
工单
作者小头像 yd_295824913 2026-10-26 00:49:27
24
0
0
2026-10-26 00:49:27
24
0
0
批处理推理的吞吐优化
做离线推理时，很多人第一反应是把 batch size 拉大。但吞吐上不去，往往不是 batch 不够大，而是下面几项没配对：序列长度分布。 一个 batch 里混着 50 token 和 4000 token 的请求，padding 会浪费大量算力。按长度分桶，比盲目加大 batch 更有效。动态批处理窗口。 窗口太短，batch 拼不满；窗口太长，延迟上升。要看业务能接受的最大等待时间，...
MapReduce
作者小头像 yd_295824913 2026-10-25 01:20:05
25
0
0
2026-10-25 01:20:05
25
0
0
微调不是 RAG 的替代品，它们解决的是不同问题
经常看到一种争论：有了微调，还需要 RAG 吗？或者有了长上下文，还需要微调吗？我的看法是，这几种技术解决的不是同一个问题，别把它们放在一个维度比较。RAG 解决的是“知识从哪来”：最新政策、内部文档、实时数据，适合检索注入。微调解决的是“行为怎么稳定”：固定格式、领域语气、分类边界、工具调用习惯，适合用样本塑造。长上下文解决的是“一次能看多少”，但不保证模型一定用好。一个实用判断：如果模型...
作者小头像 yd_295824913 2026-10-24 00:56:39
26
0
0
2026-10-24 00:56:39
26
0
0
学习的第二天！
学习的第二天！记录一下！
作者小头像 yd_295824913 2026-10-23 00:04:13
25
0
0
2026-10-23 00:04:13
25
0
0
写博客
写博客的任务
作者小头像 yd_295824913 2026-10-22 17:30:53
28
0
0
2026-10-22 17:30:53
28
0
0
https://www.baidu.com/s?ie=utf-8&f=3&rsv_bp=0&rsv_idx=1&tn=baidu&wd=sed%20%E6%9B%BF%E6%8D%A2%E5%AD%97%E7%AC%A6%E4%B8%B2&rsv_pq=c7db61a600035dc5&rsv_t=5e19yEsbV9N5fIvdlGRU
作者小头像
作者小头像
快速交付
+ 关注