BuildSpeak每日 builder 文摘
今日归档生词本关于
🐦 X · 动态Madhu Guru @realmadhuguru· 2026 年 7 月 16 日· 212 词 · 约 1 分钟

Madhu Guru · @realmadhuguru

SPACE 播放 / 暂停·←→ 上一句 / 下一句
Open-weight models like Kimi and GLM will cause a complete rethink of the enterprise AI stack. If you are running an enterprise, you need to maximimize model optionality. Here are 3 things you should be doing: 1. Evals - build rigorous evals representative of your use case (a) Regression evals - tablestakes features that should always work with high reliability (b) Aspirational / hill-climbing evals - harder use cases that the best model for your price point struggles to solve. So you scaffold it with prompting, context management and other techniques to overcome weaknesses or wait for a better model These evals should be easy and quick to run. Eval velocity is a competitive advantage. 2. Model routing - Model selection is about tradiing off quality/cost/latency for your use case. If you have good evals, you know which models to route traffic to for different use cases. This is something you ideally build yourself cos nobody understands your business and users like you do. There are off the shelf routers, but I haven't seen one I would recommend yet. 3. Model-agnostic harness - your system should never know which model is behind the API call. This means your harness normalizes prompt structure, context management, tool definitions, and output parsing across models, making it easy to switch... once your evals pass.
像 Kimi 和 GLM 这样的 open-weight models(开放权重模型)将促使企业 AI stack(AI 技术栈)被彻底重新思考。如果你在运营一家企业,就需要尽可能最大化 model optionality(模型可选性)。以下是你应该做的 3 件事:1. Evals(评测)——构建严格、能够代表你实际 use case(使用场景)的 evals。(a) Regression evals(回归评测)——那些必须始终以高可靠性正常工作的基础功能。(b) Aspirational / hill-climbing evals(目标型 / 爬坡型评测)——更难的 use case,即使在你可接受价格区间内最好的模型也难以解决。对于这类场景,你可以用 prompting(提示词设计)、context management(上下文管理)和其他技术来搭建支架,弥补模型弱点,或者等待更好的模型出现。这些 evals 应该易于且快速运行。Eval velocity(评测速度)是一种竞争优势。2. Model routing(模型路由)——模型选择本质上是在针对你的 use case 权衡 quality / cost / latency(质量 / 成本 / 延迟)。如果你有好的 evals,你就会知道针对不同 use case,应该把流量路由到哪些模型。这件事理想情况下应由你自己来构建,因为没有人比你更了解自己的业务和用户。市面上确实有现成的 router(路由器),但目前我还没见到一个我愿意推荐的。3. Model-agnostic harness(模型无关的封装层)——你的系统永远不应该知道 API 调用背后具体是哪一个模型。这意味着你的 harness 要在不同模型之间统一 prompt structure(提示结构)、context management、tool definitions(工具定义)和 output parsing(输出解析),这样一旦 evals 通过,就能轻松切换。
♥ 92↻ 7💬 4x.com ↗
原文 ↗https://x.com/realmadhuguru
BuildSpeak — 关于本项目BUILT IN PUBLIC · 跟随 builders 而非 influencers