62 篇博文 含有标签「大模型」

很多人刚开始做大模型应用时，会把上下文理解成“聊天记录”。用户说过的话越多，全部拼接给模型，似乎模型就越了解用户。

但实际情况往往相反。历史消息越长，越容易混入过期信息、无关闲聊和互相冲突的指令。模型还可能因为上下文太长而超出限制，或者忽略真正重要的内容。

科学的上下文管理不是尽可能多地塞内容，而是：

每次只给模型完成当前任务所必需、可靠、最新的信息。

大模型很擅长理解人话，也很擅长把结果组织成看起来完整的句子。但在真正的业务系统里，“看起来合理”远远不够。

比如用户让 AI 查询订单，大模型可能返回这样一段内容：

{
  "order_id": "12345",
  "include_items": true
}

这段内容看上去没有问题，可它只说明模型提出了两个参数。它没有证明订单 12345 真的存在，也没有证明当前用户有权查看这个订单。

因此，大模型应用通常需要连续做三层校验：先确认内容能不能读，再确认格式是否符合约定，最后确认它是否符合真实业务规则。

大模型会聊天，但不会干活。真正让 AI Agent 能接住复杂任务的，不是模型有多聪明，而是外面裹着的那层"缰绳"——Harness。当任务要跨多个 API、文件格式和多轮状态时，真正决定成功率的是模型外层的工程控制。

最近大模型圈有个值得关注的事：小米的 MiMo V2.5 系列开放公测了，而且在 Artificial Analysis 榜单上拿下了全球开源大模型综合智能指数第一。

一个做手机和智能家居的公司，AI 模型做到开源第一？我一开始也觉得有点意外，试了一圈之后，确实有点东西。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-24 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队一开始做 AI 系统时，会把“人在回路”理解成一种过渡方案：

• 现在模型还不够好，所以先让人兜着
• 等以后模型更强，就把人拿掉

我以前也有点这样想。后来做的系统越来越多，反而越来越不这么看了。
我现在更倾向于认为：人在回路不是妥协，而是很多 AI 系统天然就该有的一层设计。

因为很多业务问题本来就不是“把人替掉”才算成功，而是“把人的注意力放到真正值得判断的地方”才算成功。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-22 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

有一次我们为了把检索时延压下来，动了向量库的一组参数。改动本身不大，甚至可以说很“合理”：

• 降一点搜索深度
• 控一点候选数
• 让查询更快一点

结果上线后最先变化的不是延迟，而是答案味道。
用户不会告诉你“召回率下降了”，他们只会说：

• 怎么最近更容易答偏了
• 怎么有些问题又像没看文档一样

后来追回去才发现，这次参数调整表面上节省了一点查询成本，实际上悄悄改掉了检索质量的下限。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-20 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多 AI 系统前期都把预算优先给了模型、Prompt、工作流和界面，等到线上开始出问题，团队才发现真正缺的是另外三样东西：

• 观测
• 审计
• 回放

这三件事听起来像“运维附属项”，但我现在越来越把它们看成 AI 系统的基础设施。因为没有它们，系统一旦出错，你几乎无法回答最关键的几个问题：

• 这次到底发生了什么
• 为什么会发生
• 影响了哪些请求
• 新版本和旧版本比，差异到底在哪

普通系统没有日志很痛苦，AI 系统没有这三层则会很快失去可治理性。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-12 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多 AI 项目都有一个相似的阶段：Demo 已经能跑了，效果也看上去不错，于是团队会产生一种很危险的错觉，好像离“可上线服务”已经不远了。

但真正做过线上系统之后就会知道，能跑起来和能稳定提供服务，中间隔着的不是一点优化，而是一整套工程责任。

Demo 证明的是“这条链路在理想条件下成立”；
稳定服务要求的是“这条链路在真实条件下长期成立”。

真实条件包括：

• 用户输入不受控
• 上下游系统会抖
• 依赖会超时
• 流量会波动
• 模型行为会漂

能接住这些，才叫服务。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-05 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

有一阵子我们把多模型路由做得越来越“聪明”：

• 先按任务类型分
• 再按风险等级分
• 再按上下文长度分
• 再按历史命中率分
• 失败后还有二级 fallback

纸面上看，这套策略非常精细。真正上线后，问题却越来越明显：

• 成本走势很难解释
• 某个请求为什么走了某个模型很难追
• 调一条规则，别的路径会不会被带偏不清楚
• 出现效果抖动时，排查几乎像在查一个“规则黑箱”

后来我们做了一次很克制的重构：不是继续加规则，而是把路由策略砍掉一大半。结果反而更稳了。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-04 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人在算大模型私有化或自托管成本时，最容易先盯住的是两件事：

• 一张卡多少钱
• 模型需要多少显存

这两个数字当然重要，但如果只看到这里，最后经常会算出一张很“理论正确、线上失真”的成本表。
因为真实成本不是由单一硬件价格决定的，而是由推理引擎、显存占用、并发效率和服务稳定性一起决定的有效产能。

也就是说，真正该问的问题不是“这张卡贵不贵”，而是“这套栈每小时到底能稳定完成多少个有效请求”。