算法 on 小盒子的技术分享

为什么 .tar.gz 要两个后缀

Mon, 13 Apr 2026 23:00:00 +0000

前两天我在重新编译一版 nginx。

流程基本闭着眼睛都能走。wget 拉下来一个 nginx-1.27.4.tar.gz，tar -xzvf 解开，进目录，./configure，make，make install。

敲完 tar 那条命令的一瞬间，我突然愣了一下。

这个 .tar.gz，两个后缀。

我用了大概十几年，从来没认真想过为什么要两个。

顺着这事我又想起来，我这双手对 tar 的记忆完全是肌肉记忆，xzvf 这四个字母该按什么顺序，大脑是不参与的，手指自己会动。正因为是肌肉记忆，我还踩过一个经典坑，偶尔下载到没有顶层目录的 tar 包，照样一梭子解下去，几十个文件啪一下全炸到当前目录，瞬间把工作目录变成垃圾场。

那种时候我一边 ls | xargs rm 一边告诉自己下次一定先 mkdir。

但下次还是不会。

人对每天都在用的东西是最没好奇心的。

说回 .tar.gz。这两个后缀到底是什么关系，为什么非得拆成两个。

我带着这个疑问查了一圈，发现这事比我想象的有趣得多。它不是什么历史包袱，也不是约定俗成的命名习惯，它是两个时代两个工具掰着手指头拼出来的一个结果。

先说 tar。

tar 这个命令，最早出现在 1979 年 1 月的 Unix Version 7 里，AT&T 贝尔实验室做的。名字也没什么加密的缩写，就是 Tape ARchive。翻译过来，磁带归档。字面意思。

你可以想象一下 1979 年。那会儿大家备份数据靠的是磁带，就是老电影里那种两个圆盘转啊转的大盘子，数据一圈一圈顺序刻在带子上。你不能跳着读，也不能中间插一段，只能从头到尾一次性过。

tar 这个工具的出生使命，就是为了给磁带服务的。

所以它做的事情特别简单，就一个动作，把一堆小文件按顺序拼成一条长长的字节流，好让磁带机一口气写下去。

注意，我说的是「拼成一条流」。

tar 压根就不压缩。

你拿 tar 把一个 100MB 的目录打成一个包，出来的文件还是 100MB，一个字节都没省。它只是把这些东西排成一列而已，没做别的事情。

tar 文件内部的最小单位是 512 字节一块，这个数字也不是随便选的。它就是 Unix V7 文件系统磁盘扇区的大小。1979 年的一个选择，刻在所有 tar 文件的基因里，一直刻到今天。所以 tar 管的事情，就到「拼」为止。

那压缩呢？

tar 不管。

这事儿一直到 1992 年才有人接手。

那一年，两个叫 Jean-loup Gailly 和 Mark Adler 的人做了一个东西叫 gzip。Gailly 写压缩，Adler 写解压，1992 年 10 月 31 号，gzip 0.1 正式发布。

这里有个背景值得一提。在 gzip 之前，Unix 自带的压缩工具叫 compress，用的是 LZW 算法。但 LZW 被 Unisys 和 IBM 捏在手里，九十年代初开始到处收钱，开源圈被整得很紧张。gzip 就是被逼出来的替代品，用的是另一个叫 DEFLATE 的算法，完美绕开了专利地雷。

这段往事本身就够写一篇文章的，但今天我们只关心一个点。

gzip 做的事也特别简单，就一个动作，把一条字节流压缩成一条更短的字节流。

你注意到了吗？gzip 也很轴。它只认「一条流」。你不能拿 gzip 去压一个目录，它不认识目录这回事。给它一个文件，它就吐一个压缩后的文件，给它一条流，它就吐一条压缩后的流。别的事它一概不管。

tar 只打包不压缩，gzip 只压缩不打包。

两个工具，谁都不会干对方的活。

那怎么办？

中间用一根 Unix 管道粘起来。

1tar cf - mydir | gzip > mydir.tar.gz

这条命令左边 tar 把 mydir 打成一条流，用 - 表示「别写文件，直接吐到标准输出」。中间一个 |，把这条流接到 gzip 的嘴边。右边 gzip 啃完这条流，吐出一条压缩过的流，重定向到 mydir.tar.gz。

一个 | 符号，两个工具，一条流水线。

你看到的那个 .tar.gz，就是这条流水线走完之后自然掉下来的结果。它的后缀之所以是两个，是因为这个文件真的经历了两道工序。第一道叫 tar，第二道叫 gz。后缀诚实地告诉你它是谁。

这里顺便说一句 tar 后来的 -z 参数。

GNU tar 的作者们觉得每次写管道太烦，加了一个 z 参数，告诉 tar，你要压缩的时候帮我顺手调一下 gzip。这就是为什么我们今天敲 tar -xzvf 这个 z。但你要知道，是 tar 在「替你调 gzip」，不是 tar 自己会压缩。四十五年过去了，tar 本体始终没长出压缩这项能力。

这个决定非常 Unix，非常硬核。

有意思的是，几乎就在 tar 过着自己小日子的同一年代，大洋对岸的 DOS/Windows 世界走了完全不同的一条路。

1989 年，美国程序员 Phil Katz 在 DOS 上搞出 PKZIP，顺手发明了 .zip 格式。zip 跟 tar + gzip 的哲学几乎是正相反的，一个工具同时做两件事，既打包又压缩，一把梭到底。

四年之后的 1993 年，另一个年轻人进场了。俄罗斯程序员 Eugene Roshal 发布命令行 RAR，1995 年又推出图形界面版 WinRAR。RAR 是 Roshal Archive 的缩写，字面意思就是「Roshal 的归档」，一个用作者自己名字命名的格式，主打比 zip 更高的压缩率。

WinRAR 这个软件顺便还成了互联网历史上最著名的「永恒试用版」。它写着 40 天试用期，但过期后不会拦你，只会弹一个很客气的提示让你买 license，你关掉它接着用，下次再弹。这个 40 天续命了二十多年，全球无数人用了一辈子没付过钱，它也不生气。这事本身已经成了一个互联网梗。

这一路跟 Unix 那边的区别非常明显，一个软件管到底，打包压缩全包在一个 exe 里。后来 1999 年俄罗斯人 Igor Pavlov 又搞了开源的 7-Zip，自带一个 .7z 格式，压缩率再往上提一截。1996 年 Julian Seward 做的 bzip2、2009 年 Lasse Collin 做的 xz 也都先后加入了这个江湖，压缩格式的主要玩家基本就是这些人了。

但你注意到一个很好玩的分化没有。

bzip2 和 xz 这两个后来的家伙，在 Unix 世界里叫什么？.tar.bz2 和 .tar.xz。tar 先把文件拼成流，bzip2 或者 xz 接着压。换压缩工具可以，换哲学不行。Unix 那边认死一件事，打包和压缩必须是两件事，永远是两件事。

Windows 那边正相反，出了更强的算法，就把旧软件整个换掉，一个 exe 管到底。

这已经不只是格式之争了，是两个世界对「一个工具应该长成什么样」的根本分歧。

为什么 Unix 那边坚持要拆？

这就得搬出 Doug McIlroy 了。

1978 年，贝尔实验室的 McIlroy 在 Bell System Technical Journal 上写了一段后来被反复引用的话，核心就三句。

“

写程序要让它们只做一件事，并且把这件事做好。

写程序要让它们互相协作。

处理的东西最好是文本流，因为那是通用接口。

这就是后来被叫作 Unix 哲学的那一段。

但这段话最有意思的一点，不在文字本身。在于说这话的人是谁。

Doug McIlroy 不光是写这段话的人，他同时还是 Unix 管道 | 这个符号的发明者。

你品一下这个巧合。

他说「让程序互相协作」的时候，他心里想的不是什么抽象的合作，他想的就是管道。一个程序的输出，通过一根 |，无缝流进下一个程序的嘴里。小工具、单一职责、用管道粘起来，组合出任意复杂的流水线。

.tar.gz 就是这段话最直白的产物。

tar 是第一个只做一件事的小工具，gzip 是第二个只做一件事的小工具，中间那根 | 是 McIlroy 本人发明的管道。你每打一个 .tar.gz 文件，都是在重演一遍 1978 年那段话。

这就是为什么我说它是活化石。

化石这个词听起来像是死掉的东西，但 .tar.gz 不是。你今天去 GitHub 上随便点一个 C 项目的 release，下载下来的几乎永远是 .tar.gz，不是 .zip。Linux 内核、nginx、curl、redis，全都是。它不是因为惯性才活着，它是因为那套哲学在今天依然被认为是对的才活着。

所以回到开头那个问题。

为什么 .tar.gz 要两个后缀？

因为它不是一个文件，是两个工具排成的一条流水线，每个后缀对应一个工位。你看到的是这条流水线吐出来的结果。

下次你再敲 tar -xzvf some-thing.tar.gz 的时候，可以稍微多看两眼那个 z。

那个 z 不是 tar 在解压。

那是 tar 在回头喊一声 gzip，过来搭把手。

两个工具，一根管道，四十五年。

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

AI 模型推理平台架构设计与实践

Sun, 30 Nov 2025 04:11:10 +0000

一、背景

为什么要搞推理平台

从实用的角度讲，搞推理平台的目的就是为了给部署、运行、维护模型打造一个良好的 “环境”。

为什么要自己部署、运行、维护模型呢？全部用 API 不行吗？

这个问题涉及到模型的功能分化。简单来讲，传统的 LLM 基座模型是很强，类似全能型选手，但在企业落地场景下并不完全适用。企业需要的是 ROI 极高的方案，企业场景下会考虑并发、延迟、成本等非常具体的指标。所以用满足单一场景且成本极低的小模型 + 基座大模型是比较务实的选择。

一定要有 GPU （显卡资源）吗？

不一定，有些模型在 CPU 也跑的很好。比如 all-MiniLM-L6-v2，但绝大多数模型是需要 GPU 的。

二、资源规划与集群架构

我们假设你的生产环境是如下图所示的 K8S 集群环境

不止 k8s

对于一个 “模型在线推理平台（Serving 平台）”，光靠 k8s 是不够的。

如果光有 k8s 我们会遇到以下几个问题：

资源利用率极低，成本高昂：Kubernetes 的原生调度单位是 Pod。它不理解 “模型” 这个概念，也不知道如何在一张 GPU 上高效地运行多个模型。那就意味着一个模型会独占一张 GPU 卡。中小模型的计算量不大，大部分时间里，这个 Pod 和 GPU 都是空闲的。当模型数量增加时（例如 10 个或 50 个模型），成本会呈线性增长，变得非常昂贵。
运维复杂度极高：原生 Kubernetes 缺少一个更高层次的抽象来描述 “模型服务” 这个场景，必须手动组合多个底层资源来完成一个任务（手动编写和维护一套复杂的 Kubernetes YAML 文件（Deployment, Service, HorizontalPodAutoscaler 等）。
缺乏标准化的模型服务能力：这些都是应用层的逻辑，原生的 Kubernetes 并不直接提供这些开箱即用的功能

如何进行 A / B 测试或金丝雀发布（Canary Rollouts）来平滑升级模型？
如何处理模型的预处理和后处理逻辑？
如何监控模型的 QPS、延迟、成功率等指标？ 可观测性不足（难以按 “模型维度” 看指标）
流量高峰时如何自动扩容，没有流量时如何缩容以节省成本？

KServe

“

Standardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes

为了解决上述问题，社区催生了专门针对 Kubernetes 的模型服务平台，KServe 就是其中的佼佼者。它通过引入一个名为 InferenceService 的自定义资源（CRD）来解决这些问题。

解决资源利用率问题：
模型复用 (Multi-Model Serving)：KServe 可以与 NVIDIA Triton Inference Server 或 TorchServe 等高性能推理服务器集成。这些服务器支持在 单个 Pod 和单个 GPU 上加载和运行多个模型。当请求进来时，由推理服务器动态地将计算任务分配给 GPU。这样，多个中小模型就可以共享一张 GPU，极大提高资源利用率。
自动缩容至零 (Scale to Zero)：当一个模型在一段时间内没有收到任何请求时，KServe 可以自动将该模型的 Pod 缩减到 0。当新的请求到来时，它又能快速拉起一个新的 Pod 来提供服务。这对于流量不稳定的中小模型来说，是巨大的成本节省。
解决运维复杂度问题：
单一抽象 (InferenceService)：不再需要编写 Deployment, Service 等一大堆 YAML。只需要定义一个 InferenceService 对象，在里面声明用的是什么框架（TensorFlow, PyTorch, Triton 等）以及模型的存储路径（如 S3）。KServe 会自动创建和管理所有底层的 Kubernetes 资源。这极大地简化了运维工作。
解决标准化服务能力问题：
开箱即用的高级部署：在 InferenceService 的配置中，只需修改几行代码，就可以轻松实现金丝雀发布。例如，您可以指定将 10% 的流量发送到新模型，90% 的流量发送到旧模型，验证通过后再全量切换。
请求日志、监控指标：KServe 自动提供了标准化的接口和可观测性指标，方便接入 Prometheus、Grafana 等监控系统。
推理图谱 (Inference Graph)：对于需要多个模型串联（例如预处理 -> 模型 A -> 后处理 -> 模型 B）的复杂场景，KServe 也提供了标准化的解决方案。

对于 “在 Kubernetes 上部署多个中小模型” 这个场景， KServe 是目前最好、最主流的开源解决方案之一。

直接采用 KServe 将会极大降低成本、简化管理、并提升部署的稳定性和灵活性，让我们可以更专注于模型算法本身，而不是底层的基础设施。

KServe 架构

KServe 架构概览：

核心架构：

控制面架构：

数据面架构：

模型 runtime 支持：

vLLM 和 Triton

从 KServe 的运行体系图中可以看到在推理层面，大致有两种最流行的软件，一个是 vLLM，一个是 Triton

vLLM 是 LLM 专用推理引擎（只跑 Transformer，极快但单一）
Triton 通用推理平台（CV/NLP/LLM/推荐都能跑，全能但略重）

在 KServe 里，两者的选择就是： “要极速跑 LLM，还是要一车拉所有模型” 。在实践中，KServe 是一个统一平台，可以支持我们按需选引擎，所以不用 all in 其中任何一种，比较灵活、方便。

三、部署思路

架构

结构如下：

这里我们需要解释几个问题

1. 整体链路是谁在做自动扩缩容？

在 KServe + Knative 模式下，职责大致是：

KServe：
写 InferenceService CRD（YAML）
KServe Controller 把它翻译成一个 Knative Service（和一些 K8s 资源）
同时通过 annotations / 字段把我们希望的 autoscaling 配置写进去
Knative Serving：
一个 Revision
一个对应的 Deployment（里面的 Pod 跑模型容器）
一个自动伸缩器：
要么是 KPA（Knative Pod Autoscaler）
要么是一个真正的 Kubernetes HPA（如果配置了 autoscaling.knative.dev/class: hpa.autoscaling.knative.dev）
接管 Knative Service，创建：
Istio：
负责入口网关、路由、mTLS 等
把请求导入到 Knative 的 activator / queue-proxy 上
为 Knative 提供 HTTP 请求 metrics（QPS、并发等）
不直接做扩缩容决策，只是提供流量和指标
真正做扩缩容决策的是：
Knative 的 KPA 或 HPA，再通过 Deployment 控制最终 Pod 数量
KServe 只是 “声明模型 + 帮我们写好 Knative 配置”，并不直接操作 replicas

2. enable-scale-to-zero: “true” 的含义是什么？

1# 文件： knative-config.yaml
2enable-scale-to-zero: "true"

在 Knative 的 config（比如 config-autoscaler）里，表示允许某个 Knative Service 被 KPA 缩到 0 个 Pod。再配合 InferenceService / Knative Service 上的配置：

若没有设置 minScale / minReplicas，默认允许从 0 → N
若在 InferenceService 里（或 annotations）配了 minReplicas: 1 或 autoscaling.knative.dev/minScale: “1”，则不会缩到 0，而是至少保留 1 个 Pod（即 1 块 GPU 一直常驻）

缩到 0 的流程大致是：

一段时间内没有请求（由 Knative 的 autoscaler 统计）
KPA 认为可以缩减，就把 Deployment 的 replicas 降到 0
Pod 把 GPU 释放掉；节点上的 GPU 就空闲了

从 0 唤醒：

有新请求到达 Istio 网关 → 被路由到 Knative 的 Activator
Activator 缓冲请求，并通知 autoscaler
autoscaler 把 Deployment 从 0 扩到 1（或更多）个 Pod
Pod 启动，模型加载进 GPU，处理缓存的请求（这就是冷启动）

3. 单模型多 Pod ，如何占多机多卡？

把上面的流程套到 GPU 上看就是：

1. 每个推理 Pod 的容器请求：

1resources:
2 limits:
3 nvidia.com/gpu: 1
4

2. K8s 调度时确保：

每个 Pod 分配到一个有空闲 GPU 的节点
默认 nvidia.com / gpu 是「不可共享资源」，所以 1 Pod 独占 1 块卡

3. 当 autoscaler 决定从 1 Pod 扩到 N Pod 时：

K8s 再调度 N-1 个新的 Pod 到其他 GPU 节点
最终你就是：同一个模型，多 Pod，分布在多台单卡机器上
Istio / Knative 负责把请求均衡到这些 Pod 上

4. 当流量变小：

autoscaler 把 replicas 从 N 缩回 1，甚至缩到 0
对应地释放掉一部分 / 全部节点上的 GPU

总的来说：

目前有两种模式：

单模型 + 单 Pod = 占用一台单卡机
单模型 + 多 Pod = 水平扩展到多台单卡机，多卡并行处理请求

多 Pod 的自动扩缩容流程：
决策逻辑在 Knative（KPA 或 HPA）这层
KServe 只是根据 InferenceService 的 spec & annotations 帮我们创建出合适的 Knative Service / autoscaler 配置
Istio 不做扩缩容决策，只负责网关和路由，同时为 Knative 提供 metrics / 流量通路
enable-scale-to-zero: “true” 是 Knative 的全局开关，允许在 InferenceService 里配置成真正可缩到 0 的无流量模型服务。

面临的问题

整个架构从水平扩容的角度讲是没有太大的问题，但当我们把视角切换到机器内部，看 pod 内部的情况，是有问题的，比如：

一个显卡 48G 显存，一个小模型可能只需要 10G 显示，但它独占了一张显示，这会造成资源的浪费
当我只有一两个模型需要部署时候问题不大。浪费也不大，但如果我有多个小模型（单卡能放下）都需要同时部署，如果不仔细计算显卡的使用率，那么有可能造成大量的资源浪费。

解决办法

对一个 LLM 来说，显存大致分三块：

模型权重（weights）
运行时开销（activations / 临时 buffer 等）
KV Cache（连续 batching 的关键，vLLM 会尽可能把剩余显存拿来做这个）VLLM Docs

vLLM 通过 –gpu-memory-utilization 控制 “自己能用的显存占比”（默认 0.9），在这个额度内，剩下的空间基本都会拿去做 KV Cache，以提升吞吐和并发。

所以：

如果我们看到 “模型只占 10G”，很可能只是在低并发、短上下文下的一瞬间观感；
一旦并发、上下文长度、请求峰值上去，KV Cache 会吃掉大量显存，这时候那 “剩余的 30+ G” 就会逐步被用起来。

如果在业务高峰期，这几个指标都比较高（比如显存长期 >70%，KV cache 使用率也不低），那 “单模型独占一张卡” 并不浪费，而是在换 性能 & 稳定性。

其实我们问题的本质是：“我有好几种小模型都要在线，单卡其实装得下，但一机一模型的部署方式会造成卡粒度上的浪费。”

要解决这个问题，大致有几条思路：按 “现实可行度” 从高到低排序：

业务层合并：能不用多模型就别用多模型

能用一个 “能力足够强” 的主模型 + Prompt / LoRA 搞定，就不要真部署 N 个完全独立的小模型。
多数 “业务小模型” 的差异，其实是 “提示词 + 风格 + LoRA” 的区别，不一定非要上不同 base model。

把单模型的吞吐吃满

利用 vLLM 的连续 batching，提高并发、适当增加最大上下文、控制 QPS，让 GPU 真正跑到比较高的利用率。
我们已经有完整的 Prometheus / Grafana 看板方案，可以直接看 QPS、Token 吞吐、GPU Util、KV Cache 占用来调优。

实在必须多模型同卡，再考虑 “共享 GPU” 技术（下面会拆开说）

共享 GPU 技术

Time-Slicing

NVIDIA GPU Operator / k8s-device-plugin 提供的 Time-Slicing，本质是：

把一张物理 GPU 虚拟成多个 “replica” 资源，Pod 申请 nvidia.com / gpu: 1 时，拿到的是其中一个 replica；
底层靠时间片轮转在同一张卡上跑多个 Pod。

关键点（也是坑点）是：Time-Slicing 只切算力，不切显存，显存是共享的，没有隔离。NVIDIA Docs 这意味着：

如果多个 Pod 加起来申请 / 实际占用的显存 > 实际物理显存，就有概率 OOM；
即使不 OOM，Page Fault / 内存碎片也会让延迟非常不稳定。

而 vLLM 非常依赖稳定且持续的显存做 KV Cache，Time-Slicing 没有显存隔离，很容易被别的 Pod 挤爆显存导致 OOM，所以不适合 vLLM

MIG（Multi-Instance GPU）

MIG 的特点：

真正把 一张 GPU 切成多个硬件隔离的 “小卡”，每块有独立的显存、高带宽内存、缓存和计算核心
适合需要 延迟可预测、多租户隔离 的 LLM 推理场景

但 MIG 只在 A100 / H100 / A30 等特定卡上存在，普通云上 L4、L40、T4、V100 这类要么不支持，要么支持非常有限。对于我们来说，也不适用。

ModelMesh

KServe 其实就内置了两种 “模型平台形态”：1. Single-Model Serving（单模型平台）

每个服务只跑一个模型；
LLM / 大模型几乎都是走这一条（包括 vLLM Runtime）。2. Multi-Model Serving（基于 ModelMesh 的多模型平台）
同一个模型服务器里可以放多模型，按需加载/卸载，适合一堆小模型共享有限卡的场景（比如 SKLearn/ONNX/OpenVINO 那些）。

ModelMesh 适合「很多模型 + 访问稀疏」的场景，ModelMesh 的设计目标是：

管理大量模型（几十、几百甚至更多）
很多模型 QPS 很低，没必要长时间常驻显存 / 内存
通过「按需加载 + LRU 驱逐」来平衡：
内存 / 显存占用
冷启动延迟

另外，社区对 ModelMesh 的定位也比较明确：更偏向 “可伸缩多模型平台”，现在要把 LLM Runtime（特别是 vLLM）硬往 ModelMesh 里塞，是有一定探索和集成成本的，而且生态也还在演进中 https://github.com/kserve/kserve/issues/4299

如果我们前期的目标只是「十个以内」的小模型，希望高利用率、简单稳定，所以可以先不用 ModelMesh，真正到模型数爆炸、并且很多模型很冷时，再考虑 ModelMesh 会更合适。尤其是当前的重点是 “先把核心 LLM 跑稳定 & 可观测 & 易扩容”。

Triton + vLLM + 多模型同 Pod / 同 GPU

以上方案都不太合适，于是我把目光投向了 Triton

NVIDIA Triton 的能力是比较强的：

支持在同一台机器上多个模型 / 多个模型实例并行执行，由 Triton 负责调度；NVIDIA Docs
支持多种后端（TensorRT-LLM、PyTorch、ONNXRuntime、Python backend 等）；
现在还有 官方的 vLLM backend，可以在 Triton 里用 vLLM 做 LLM 推理。

从 GPU 视角看，Triton 做的事类似于：“一个进程负责管理很多模型，来了请求就把对应的 op 丢给 GPU，GPU 再在硬件层面做调度并发。” 但是：Triton 也不会神奇地帮我们 “切显存”—— 多个模型的权重 + KV Cache 依然是往同一个物理显存里塞。Triton 提供的是 “共享一块显存的多模型协调器”，不是 “把显存分成几块小卡” 的硬隔离器。

因此：

Triton 不能像 MIG 一样说：
“模型 A 只能用 16G，模型 B 只能用 8G，互相绝不会越界”
它顶多是：
通过配置 + 调度让你 “尽量别把自己搞到 OOM”；
但如果你把几个模型配置得都很激进，合起来 > 物理显存，照样可能 OOM，仅仅是更 “有迹可循”。

结合我们的实际情况，综合考虑，Triton 可以有以下几种组合姿势：

Triton 只负责传统模型（embedding、CV、语音等），LLM 仍由独立 vLLM 服务跑

这时候 “一卡多模型” 主要是非 LLM 模型之间的事，LLM 是单卡独占或少量共享；
对现在的 “私有化大模型平台” 来说，这是最现实、也最可控的一种搭配。

Triton + vLLM backend，把 LLM 也塞进 Triton 的统一服务里

本质上还是 “一张卡一个 vLLM 引擎”，只是对外通过 Triton 统一暴露接口而已；
多模型同卡时，显存依然一起抢；如果你试图放多个 LLM（哪怕是 7B SLM），很快就会撞上显存天花板，需要极其克制的 –gpu-memory-utilization 和并发控制。

Triton 内部多 LLM + 非 LLM 模型混合

这种组合在理论上可行，工程上可做，但对资源规划、监控、故障排查的要求会非常高；
对现在来说，属于 “下一阶段再考虑” 的东西

综上，目前我们利用 Triton 采用第一种方式：负责传统模型（embedding、CV、语音等），LLM 仍由独立 vLLM 服务跑

对所有私有化部署的模型部署整体策略如下：

“

上图是从 KServe 视角看的，如果从 k8s 视角，不同的 pod 还会有多副本扩容的情况。但每个 pod 都是独占 GPU。

Triton 多模型（非 LLM）分组方案

整体思路：1 GPU 1 Triton，多模型共用

在现有架构下，最自然的做法是：

每块 GPU 起一个 Triton Pod（由一个 InferenceService 管）
这个 Triton Pod 里面的 model repository 里放多个非 LLM 模型：embedding / rerank / CV / ASR…
KServe 只是负责：
帮我们起 kserve-tritonserver 这个 runtime
把远端（S3/MinIO/PVC）上的 Triton model repository 挂到 /models（或 /mnt/models）
暴露统一的 HTTP / gRPC 入口（/v2/models//infer）

Triton 本身就是为「一台机上多个模型、多个实例并发」设计的：多个模型、多个实例可以在同一块卡上并发执行，通过 instance_group、dynamic_batching 来调度和吃满卡资源。NVIDIA Docs

建议按业务域 + 性能特性分组：

一组：文本向量 + rerank（text-embedder / text-reranker）
一组：CV / OCR / ASR（图像 & 语音）这样：
同一组内模型的 batch 维度、输入大小比较接近，Triton 的 dynamic batching 比较好调；
资源隔离更清晰：文本这组爆了不会影响语音那组。

下面是一套完整配置样例（可以先从「所有非 LLM 都放一个组」开始，后面再拆分）

分组示例

Triton 模型仓库（model repository）结构示例，Triton 要求的模型仓库布局类似这样：

 1 s3://your-bucket/triton-nonllm-repo/
 2├── text-embedding-e5-small/
 3│ ├── config.pbtxt
 4│ └── 1/
 5│ └── model.onnx
 6├── text-rerank-msmarco/
 7│ ├── config.pbtxt
 8│ └── 1/
 9│ └── model.onnx
10├── vision-cls-resnet50/
11│ ├── config.pbtxt
12│ └── 1/
13│ └── model.onnx
14├── asr-conformer/
15│ ├── config.pbtxt
16│ └── 1/
17│ └── model.onnx
18└── search-pipeline/
19 ├── config.pbtxt # 可选：Triton ensemble，把 embedder + reranker 串起来
20 └── 1/
21 └── model.graphdef / model.py / ...

只要 storageUri 指向这个目录，Triton 就会把子目录当成多个模型一起加载。

单个模型的 config.pbtxt 示例（带分组 / 实例配置），以一个 ONNX embedding 模型为例：路径：text-embedding-e5-small/config.pbtxt

 1name: "text-embedding-e5-small"
 2platform: "onnxruntime_onnx"
 3max_batch_size: 128 # 这里根据你的 embedding 模型实际情况调
 4
 5input [
 6 {
 7 name: "input_ids"
 8 data_type: TYPE_INT64
 9 dims: [ -1 ] # 序列长度，-1 表示动态
10 },
11 {
12 name: "attention_mask"
13 data_type: TYPE_INT64
14 dims: [ -1 ]
15 }
16]
17
18output [
19 {
20 name: "embedding"
21 data_type: TYPE_FP32
22 dims: [ 768 ] # 或者你的模型真实向量维度
23 }
24]
25
26# 关键：在同一块 GPU 上开多实例，提高吞吐
27instance_group [
28 {
29 kind: KIND_GPU
30 count: 2 # 这块卡上起两个实例，看显存情况调 1/2/3
31 }
32]
33
34# 关键：Dynamic Batching，让 Triton 自动拼 batch
35dynamic_batching {
36 preferred_batch_size: [ 8, 16, 32, 64 ]
37 max_queue_delay_microseconds: 2000 # 2ms 内尽量攒一波请求
38}
39

同理，你可以为其他模型写各自的 config.pbtxt。分组思路：

对 高 QPS 的模型（比如 text embedding）可以把 max_batch_size 和 preferred_batch_size 设得大些，多起几个 instance_group；
对 低 QPS 但重模型（ASR、复杂 CV）就用 max_batch_size 小一点，甚至单实例。

如果有完整的 pipeline（比如「embedding → rerank」），可以用 Triton 的 ensemble 在 search-pipeline/config.pbtxt 里把两个模型串起来，一次请求走一条 DAG，减少网络往返。

KServe InferenceService YAML 示例（kserve-tritonserver）

KServe 自带 kserve-tritonserver 这个 ClusterServingRuntime，支持 TensorFlow / ONNX / PyTorch / TensorRT 模型。可以这样起一个「非 LLM 小模型专用」的 Triton 服务：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: triton-nonllm-text
 5 namespace: ai-serving
 6 annotations:
 7 # Knative 自动扩缩容（按并发）
 8 autoscaling.knative.dev/metric: "concurrency"
 9 autoscaling.knative.dev/target: "10" # 每 Pod 目标并发
10 autoscaling.knative.dev/minScale: "1"
11 autoscaling.knative.dev/maxScale: "5"
12spec:
13 predictor:
14 # ✅ 新 schema：通过 model.runtime 显式指定使用 kserve-tritonserver
15 model:
16 modelFormat:
17 # 这里写实际模型格式（比如 onnx / pytorch），只要包含在 kserve-tritonserver 支持列表中即可
18 # Triton 仓库里可以混放多种 backend，KServe 不会限制这一层
19 name: onnx
20 runtime: kserve-tritonserver
21 # 指向刚才那个包含多个模型的 Triton 模型仓库
22 storageUri: s3://your-bucket/triton-nonllm-repo
23 runtimeVersion: "24.03-py3" # 按你集群里安装的 kserve-tritonserver 版本改
24 # 如需 gRPC（性能更好），参考官方示例暴露 9000 端口:contentReference[oaicite:6]{index=6}
25 ports:
26 - name: h2c
27 protocol: TCP
28 containerPort: 9000
29 resources:
30 requests:
31 cpu: "4"
32 memory: "16Gi"
33 nvidia.com/gpu: 1
34 limits:
35 cpu: "8"
36 memory: "32Gi"
37 nvidia.com/gpu: 1
38 nodeSelector:
39 gpu-pool: "true" # 按你集群里标的 label 改，确保调度到有 GPU 的节点
40

几点说明：

多模型是 Triton 内部概念

KServe 看到的只是「一个 InferenceService + 一个 Triton Pod」。
Triton 会根据 storageUri 下的目录加载多个模型。

请求路径

走 KServe / Istio / Knative 的网关时：
HTTP：POST http:///v2/models//infer
gRPC：grpc://:/InferenceServer/ModelInfer（按 Triton V2 协议）
就是每个子目录名：text-embedding-e5-small / vision-cls-resnet50 / asr-conformer…

简单 Checklist：

准备 Triton 模型仓库

在 MinIO / S3 / PVC 上建好 triton-*-repo 目录；
把 embedding、rerank、CV、ASR 模型按 Triton 要求拆目录 + 写 config.pbtxt。

确认集群里有 kserve-tritonserver 的 ClusterServingRuntime

kubectl get clusterservingruntime | grep triton

应用上面那个 InferenceService YAML

改好 storageUri、runtimeVersion、nodeSelector；

通过 /v2/models//infer 分别打 smoke test

文本 embedding / rerank / CV / ASR 各来几条请求；
对比 Triton metrics（/metrics）和 DCGM，看 GPU 利用率 & 显存占用。

请求流 & 监控流（两条主链路）

推理请求链路（从客户端到 vLLM）

KServe 把 InferenceService 抽象出来，底层仍然是 Knative Service + Istio VirtualService 这些资源；Istio ServiceMesh 文档里也有 “给 InferenceService 打 sidecar 做安全 / 流量治理” 的说明。
vLLM 服务端会在 /metrics 上暴露自身的 Prometheus 指标，例如 vllm:prompt_tokens_total、vllm:generation_tokens_total、vllm:e2e_request_latency_seconds 等，用来统计 QPS、Token 数量和端到端延迟。

监控链路（业务 + GPU）

NVIDIA 官方文档明确建议：在 Kubernetes 中监控 GPU 时，使用 DCGM Exporter → Prometheus → Grafana 这一条链路。
我们现在的设计就是把这一套和 vLLM 的业务 metrics 汇总到同一个 kube-prometheus-stack 里 —— 这也是很多实践里推荐的做法，用 Prometheus Operator 的 ServiceMonitor 去发现所有 exporter 与应用。

在 K8s 里做 GPU 监控，典型链路是：

“

GPU 节点 → GPU Operator → DCGM Exporter → Prometheus → Grafana

GPU Operator：在 GPU 节点上自动装好驱动、Container Toolkit、Device Plugin、DCGM / Exporter 等一整套 GPU 栈。
DCGM Exporter：基于 NVIDIA DCGM，把 GPU 的利用率、显存、温度、功耗等指标以 Prometheus /metrics 的形式暴露出来。
NVIDIA 官方推荐：在 K8s 集群里采集 GPU Telemetry，就用 DCGM Exporter + Prometheus + Grafana 这一套。
GPU Operator 默认就会启用 DCGM Exporter 来采集 GPU metrics（可以通过 Helm values 里的 dcgmExporter.enabled 开关）。

所以，我们只需要：

在 Kubekey 装好的 K8s 集群中安装 GPU Operator（包含 DCGM Exporter）。
在公司统一 Prometheus 上加一个 scrape job（或者在集群里用 ServiceMonitor），把这些 /metrics 抓过去即可

“

GPU Operator 是一个管理者，DCGM Exporter 是它管理的一个组件。你只和管理者（Operator）打交道，它会帮你搞定一切。

四、环境搭建步骤

需要安装的软件、版本及顺序

安装步骤 SOP

第 0 步：准备工作

1# 添加所有需要的 Helm 仓库
2helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
3helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
4helm repo add jetstack https://charts.jetstack.io
5helm repo add istio https://istio-release.storage.googleapis.com/charts
6helm repo update

第 1 步：安装 NVIDIA GPU Operator (v24.9.1)

目的：启用 GPU 驱动，并配置 CDI (Container Device Interface) 以兼容 K8s 1.30。

以下命令是在 GPU 驱动都安装好的前提下执行

1helm install gpu-operator nvidia/gpu-operator \
2 -n gpu-operator --create-namespace \
3 --version v24.9.1 \
4 --set driver.enabled=false \
5 --set toolkit.enabled=true \
6 --set cdi.enabled=true \
7 --set cdi.default=true
8

验证：等待 kubectl get pods -n gpu-operator 全绿。

如果出错，那么：

这个命令显式指定了版本，并且强制告诉 Operator 你的 Containerd 配置文件在哪里，避免出现之前的 FailedCreatePodSandBox 错误。

 1helm install gpu-operator nvidia/gpu-operator \
 2 -n gpu-operator --create-namespace \
 3 --version v24.9.1 \
 4 --set driver.enabled=false \
 5 --set toolkit.enabled=true \
 6 --set toolkit.env[0].name=CONTAINERD_CONFIG \
 7 --set toolkit.env[0].value=/etc/containerd/config.toml \
 8 --set toolkit.env[1].name=CONTAINERD_SOCKET \
 9 --set toolkit.env[1].value=/run/containerd/containerd.sock \
10 --set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
11 --set toolkit.env[2].value=nvidia \
12 --set cdi.enabled=true \
13 --set cdi.default=true

第 2 步：安装 Kube-Prometheus-Stack (v61.9.0)

目的：基础监控。必须修正配置，否则 KServe 的 ServiceMonitor 会被忽略。

准备 values-kube-prometheus-stack.yaml

 1# values-kube-prometheus-stack.yaml
 2
 3prometheus:
 4 prometheusSpec:
 5 # 允许抓取所有 namespace 下的 ServiceMonitor / PodMonitor
 6 serviceMonitorNamespaceSelector: {}
 7 podMonitorNamespaceSelector: {}
 8
 9 # 不再强制使用 Helm 的 release label 做筛选
10 # （默认是 true，会要求 ServiceMonitor 带 release=<helm release> 这样的 label）
11 serviceMonitorSelectorNilUsesHelmValues: false
12 podMonitorSelectorNilUsesHelmValues: false
13
14 # 空 selector = 不按 label 过滤，看到就抓
15 serviceMonitorSelector: {}
16 podMonitorSelector: {}
17
18 # 可选：Prometheus 数据保留时间
19 retention: 15d
20
21 # 暴露 Prometheus 的方式（开发环境方便直接 NodePort）
22 service:
23 type: NodePort
24 nodePort: 30090 # 访问地址：任一节点IP:30090 
25
26grafana:
27 # Grafana 用 NodePort 方便先调试；生产看你们自己安全策略
28 service:
29 type: NodePort
30 nodePort: 30080 # 可不填，让 kube 随机分配
31
32 # 管理员密码（不写一般是 prom-operator，也可以明确写死）
33 adminPassword: prom-operator

这套配置的核心就是：Prometheus 不再只认「带 release=kube-prometheus-stack 的 ServiceMonitor」，而是「所有 namespace 下的 ServiceMonitor 都抓」，这样 GPU Operator 自动创建的 ServiceMonitor 也不会漏掉。

安装 kube-prometheus-stack

1helm install monitoring prometheus-community/kube-prometheus-stack \
2 -n monitoring --create-namespace \
3 --version 61.9.0 \
4 -f values-kube-prometheus-stack.yaml

打开 GPU Operator 的监控组件（ServiceMonitor）

1#解释：
2#--reuse-values: 保留之前设置的 cdi.enabled=true 等参数。
3#--set dcgmExporter.serviceMonitor.enabled=true: 这才是核心，告诉 Operator 创建监控对象。
4
5helm upgrade gpu-operator nvidia/gpu-operator \
6 -n gpu-operator \
7 --reuse-values \
8 --set dcgmExporter.serviceMonitor.enabled=true

第 3 步：安装 Cert-Manager (v1.15.3)

目的：为 KServe 和 Knative 的 Webhook 签发自签名证书。

1helm install cert-manager jetstack/cert-manager \
2 -n cert-manager --create-namespace \
3 --version v1.15.3 \
4 --set crds.enabled=true

验证：等待 kubectl get pods -n cert-manager 全绿。

第 4 步：安装 Istio (v1.22.6)

目的：流量网关。严格按照 Base -> Istiod -> Gateway 的顺序安装。

1# 1. 安装 Base CRD
2helm install istio-base istio/base -n istio-system --create-namespace --version 1.22.6
3
4# 2. 安装 Istiod 控制平面
5helm install istiod istio/istiod -n istio-system --version 1.22.6 --wait
6
7# 3. 安装 Ingress Gateway (数据平面)
8helm install istio-ingressgateway istio/gateway -n istio-system --version 1.22.6

第 5 步：安装 Knative Serving & Net-Istio (v1.15.1)

目的：实现 Serverless 扩缩容能力。

1# 1. 安装 CRDs
2kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.2/serving-crds.yaml
3
4# 2. 安装 Serving Core
5kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.2/serving-core.yaml
6
7# 3. 安装 Net-Istio (网络适配器)
8kubectl apply -f https://github.com/knative-extensions/net-istio/releases/download/knative-v1.15.1/net-istio.yaml

验证：kubectl get pods -n knative-serving，确保 net-istio-controller 和 activator 状态为 Running。

第 6 步：安装 KServe (v0.14.1)

目的：核心推理平台。注意这里使用的是 v0.14.1。

1# 安装 KServe CRDs
2helm install kserve-crd oci://ghcr.io/kserve/charts/kserve-crd \
3 --version v0.14.1 \
4 -n kserve --create-namespace
5 
6# 安装 KServe Controller
7helm install kserve oci://ghcr.io/kserve/charts/kserve \
8 --version v0.14.1 \
9 -n kserve

执行完上述两条命令后，检查 KServe 的系统组件： kubectl get pods -n kserve

第 7 步：配置 vLLM Runtime (关键)

KServe 默认只有简单的 CPU 模型支持。为了运行公司级 LLM 服务，必须添加支持 GPU 的 Runtime。

保存以下内容为 vllm-runtime.yaml 并执行 kubectl apply -f vllm-runtime.yaml：

 1apiVersion: serving.kserve.io/v1alpha1
 2kind: ClusterServingRuntime
 3metadata:
 4 name: kserve-vllm
 5spec:
 6 annotations:
 7 prometheus.kserve.io/port: '8080'
 8 prometheus.kserve.io/path: "/metrics"
 9 supportedModelFormats:
10 - name: vllm
11 version: "1"
12 autoSelect: true
13 containers:
14 - name: kserve-container
15 image: vllm/vllm-openai:latest
16 # 建议生产环境锁定具体 image sha256
17 command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
18 args:
19 - --port=8080
20 - --model=/mnt/models
21 - --gpu-memory-utilization=0.9
22 env:
23 - name: PORT
24 value: "8080"
25 resources:
26 requests:
27 cpu: "4"
28 memory: "16Gi"
29 nvidia.com/gpu: "1"
30 limits:
31 cpu: "8"
32 memory: "32Gi"
33 nvidia.com/gpu: "1"

第 8 步：为 GPU 调度开启 Knative 的 nodeSelector / tolerations

Knative 默认禁止你在 Knative Service 的 Pod 里写 nodeSelector / tolerations，KServe 官方教程在使用 GPU 时也会做这一步 patch。

打开特性开关

1kubectl patch configmap/config-features \
2 --namespace knative-serving \
3 --type merge \
4 --patch '{"data":{"kubernetes.podspec-nodeselector":"enabled", "kubernetes.podspec-tolerations":"enabled"}}'

重启 Webhook：

1kubectl delete pod -n knative-serving -l app=webhook

第 9 步：Istio Sidecar 注入策略（避免影响 GPU Operator 和监控）

默认 Istio 只对打了 istio-injection=enabled 标签的 namespace 注入 sidecar。确保「不需要注入」的 namespace 没有 label

保护基础设施 (防止 Sidecar 导致 Job 不退出)

1# 1. 明确禁止 GPU Operator 注入 (防止 Validator/Driver 安装卡死)
2kubectl label namespace gpu-operator istio-injection=disabled --overwrite
3
4# 2. 明确禁止 监控 注入 (减少开销)
5kubectl label namespace monitoring istio-injection=disabled --overwrite
6
7# 3. 明确禁止 kube-system 注入 (安全底线)
8kubectl label namespace kube-system istio-injection=disabled --overwrite

保护控制平面 (防止 Webhook 超时)

1
2kubectl label namespace knative-serving istio-injection=disabled --overwrite 
3kubectl label namespace kserve istio-injection=disabled --overwrite

启用业务空间 (让模型享受 Service Mesh 能力)，业务命名空间 “必须” 注入 ✅

1# 1. 创建你的业务空间 (如果你还没创建)
2kubectl create namespace model-serving
3# 2. 启用注入 (关键一步)
4kubectl label namespace model-serving istio-injection=enabled --overwrite

这样做的好处：

GPU Operator、DCGM Exporter、Prometheus 不会被 sidecar 干扰
模型推理流量全部走 Istio + Knative 控制的入口

第 10 步：安装 MinIO（可选）

添加所有依赖 Helm 仓库

1# 添加MinIO、Loki官方仓库
2helm repo add minio https://helm.min.io/
3helm repo add grafana https://grafana.github.io/helm-charts
4# 更新所有仓库（确保获取最新Chart版本）
5helm repo update

MinIO 部署 —— 部署 2 节点分布式 MinIO（Loki 后端存储） MinIO 配置为 2 副本分布式，适配当前 2 节点，同时预留未来扩容参数，升级时仅需修改副本数即可。

编写 MinIO 配置文件 minio-distributed-values.yaml

关键标注：文件内 replicas 和 numberOfNodes 为扩容核心参数，未来扩容需同步修改为 3+ 等节点数。

 1# 核心：启用分布式模式（2节点适配，未来扩容改replicas/numberOfNodes）
 2mode: distributed
 3replicas: 2 
 4numberOfNodes: 2 
 5
 6# 镜像配置（你原单节点的成功版本）
 7image:
 8 repository: quay.io/minio/minio
 9 tag: RELEASE.2023-07-07T07-13-57Z
10 pullPolicy: IfNotPresent
11
12# 访问密钥（完全沿用你的配置，Loki对接需一致）
13rootUser: U4DwltABIX8p20aONyoY 
14rootPassword: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm 
15
16# 持久化存储配置（你的成功配置，保障数据持久化）
17persistence:
18 enabled: true
19 storageClass: "" # 使用集群默认存储类
20 size: 10Gi 
21 mountPath: /export
22
23# 服务配置（集群内访问，无需暴露外网）
24service:
25 type: ClusterIP
26 port: 9000 # S3兼容接口端口（Loki对接用）
27consoleService:
28 type: ClusterIP
29 port: 9001 # 管理控制台端口（可选）
30
31# 默认Bucket（Loki日志存储专用，自动创建，无需手动操作）
32defaultBucket:
33 enabled: true
34 name: loki-chunks  # Loki配置需与该Bucket名一致
35 policy: read-write
36 purge: false # 卸载MinIO时保留数据
37
38# 资源限制（适配测试环境，低资源占用）
39resources:
40 requests:
41 cpu: 100m
42 memory: 512Mi
43 limits:
44 cpu: 500m
45 memory: 1Gi
46
47# 健康检查（分布式启动稍慢，微调延迟避免探针失败）
48livenessProbe:
49 initialDelaySeconds: 90
50 periodSeconds: 10
51readinessProbe:
52 initialDelaySeconds: 60
53 periodSeconds: 5
54
55# 跨节点调度策略（强制2个副本分布在不同节点，保障高可用）
56affinity:
57 podAntiAffinity:
58 requiredDuringSchedulingIgnoredDuringExecution:
59 - labelSelector:
60 matchExpressions:
61 - key: app.kubernetes.io/name
62 operator: In
63 values:
64 - minio
65 topologyKey: kubernetes.io/hostname
66
67# 安全配置（确保权限足够）
68securityContext:
69 runAsUser: 0
70 runAsGroup: 0
71 fsGroup: 0
72
73# 监控集成（默认关闭，若需对接Prometheus可改为true）
74metrics:
75 enabled: false
76 serviceMonitor:
77 enabled: false

安装分布式 MinIO

1helm install minio minio/minio \
2 -n monitoring \
3 --version 5.4.0 \
4 -f minio-distributed-values.yaml

验证 MinIO 部署（2 节点核心检查）

1# 查看MinIO Pod状态（2个副本均为Running，分布在不同节点）
2kubectl get pods -n monitoring -o wide | grep minio
3
4# 查看MinIO Service（地址固定，扩容后不变）
5kubectl get svc -n monitoring | grep minio
6
7# 验证桶创建成功
8kubectl exec -n monitoring minio-0 -- mc ls minio
9# 预期输出：[2024-xx-xx xx:xx:xx UTC] DIR loki-data

创建存储桶

Loki 的 ConfigMap 中指定了两个桶：chunks（存储日志块）、ruler（存储规则），先在 MinIO 中手动创建这两个桶（避免 Loki 首次写入时因桶不存在报错）：

1# 进入minio-0 Pod，创建chunks和ruler桶
2kubectl exec -it minio-0 -n monitoring -- /bin/sh -c "
3 /usr/local/bin/mc alias set minio http://localhost:9000 U4DwltABIX8p20aONyoY 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm --api S3v4 &&
4 /usr/local/bin/mc mb minio/chunks --ignore-existing &&
5 /usr/local/bin/mc mb minio/ruler --ignore-existing &&
6 echo '✅ Loki所需的chunks和ruler桶创建成功' &&
7 /usr/local/bin/mc ls minio # 验证桶是否存在
8"

第 11 步：安装 Loki 和 Promtail

编写 Loki 配置文件（loki-values.yaml）

 1autoscaling:
 2 enabled: true
 3 maxReplicas: 5
 4 minReplicas: 2
 5 targetCPUUtilizationPercentage: 70
 6 targetMemoryUtilizationPercentage: 80
 7backend:
 8 persistence:
 9 enabled: true
10 size: 10Gi
11 storageClass: local
12 replicas: 2
13 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
14 readinessProbe:
15 initialDelaySeconds: 60
16 timeoutSeconds: 10
17canary:
18 enabled: false
19gateway:
20 enabled: false
21grafanaAgent:
22 enabled: false
23image:
24 tag: 2.9.2
25loki:
26 auth_enabled: false
27 limits_config:
28 retention_period: 720h
29 schemaConfig:
30 configs:
31 - index:
32 period: 24h
33 prefix: index_
34 object_store: s3
35 schema: v11
36 store: boltdb-shipper
37 storage:
38 config:
39 s3:
40 access_key_id: U4DwltABIX8p20aONyoY
41 bucketnames: chunks  # 匹配MinIO已创建的chunks桶
42 endpoint: minio:9000 # 保留你原有简写地址，不改动
43 insecure: true
44 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
45 s3forcepathstyle: true # MinIO必需的核心配置
46 type: s3
47read:
48 replicas: 2
49 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
50 readinessProbe:
51 initialDelaySeconds: 60
52 timeoutSeconds: 10
53resources:
54 limits:
55 cpu: 1000m
56 memory: 2Gi
57 requests:
58 cpu: 300m
59 memory: 768Mi
60write:
61 persistence:
62 enabled: true
63 size: 20Gi
64 storageClass: local
65 replicas: 2
66 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
67 readinessProbe:
68 initialDelaySeconds: 60
69 timeoutSeconds: 10

部署 Loki

1# 部署Loki
2helm install loki grafana/loki -n monitoring \
3 -f loki-values.yaml \
4 --version 5.36.0

Loki ConfigMap:

 1apiVersion: v1
 2data:
 3 config.yaml: |2
 4
 5 auth_enabled: false
 6 common:
 7 compactor_address: 'loki-backend'
 8 path_prefix: /var/loki
 9 replication_factor: 1
10 storage:
11 s3:
12 bucketnames: chunks
13 # 新增：MinIO集群内服务地址
14 endpoint: minio.monitoring.svc.cluster.local:9000
15 # 新增：MinIO的Access Key
16 access_key_id: U4DwltABIX8p20aONyoY
17 # 新增：MinIO的Secret Key
18 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
19 # 修正：MinIO未开启HTTPS，改为true
20 insecure: true
21 # 修正：MinIO必须开启路径风格，改为true
22 s3forcepathstyle: true
23 frontend:
24 scheduler_address: query-scheduler-discovery.monitoring.svc.cluster.local.:9095
25 frontend_worker:
26 scheduler_address: query-scheduler-discovery.monitoring.svc.cluster.local.:9095
27 index_gateway:
28 mode: ring
29 limits_config:
30 enforce_metric_name: false
31 max_cache_freshness_per_query: 10m
32 reject_old_samples: true
33 reject_old_samples_max_age: 168h
34 retention_period: 720h
35 split_queries_by_interval: 15m
36 memberlist:
37 join_members:
38 - loki-memberlist
39 query_range:
40 align_queries_with_step: true
41 ruler:
42 storage:
43 s3:
44 bucketnames: ruler
45 # 新增：MinIO集群内服务地址
46 endpoint: minio.monitoring.svc.cluster.local:9000
47 # 新增：MinIO的Access Key
48 access_key_id: U4DwltABIX8p20aONyoY
49 # 新增：MinIO的Secret Key
50 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
51 # 修正：MinIO未开启HTTPS，改为true
52 insecure: true
53 # 修正：MinIO必须开启路径风格，改为true
54 s3forcepathstyle: true
55 type: s3
56 runtime_config:
57 file: /etc/loki/runtime-config/runtime-config.yaml
58 schema_config:
59 configs:
60 - index:
61 period: 24h
62 prefix: index_
63 object_store: s3
64 schema: v11
65 store: boltdb-shipper
66 server:
67 grpc_listen_port: 9095
68 http_listen_port: 3100
69 storage_config:
70 hedging:
71 at: 250ms
72 max_per_second: 20
73 up_to: 3
74kind: ConfigMap
75metadata:
76 annotations:
77 meta.helm.sh/release-name: loki
78 meta.helm.sh/release-namespace: monitoring
79 creationTimestamp: "2025-11-24T08:14:03Z"
80 labels:
81 app.kubernetes.io/instance: loki
82 app.kubernetes.io/managed-by: Helm
83 app.kubernetes.io/name: loki
84 app.kubernetes.io/version: 2.9.2
85 helm.sh/chart: loki-5.36.0
86 name: loki
87 namespace: monitoring
88 resourceVersion: "8228076"
89 uid: 103b336c-fcb1-4516-85d8-76d45ca6c79d

验证 Loki 部署

1# 查看Loki核心组件（read/write/backend均需Running）
2kubectl get pods -n monitoring | grep -E "loki-read|loki-write|loki-backend"
3# 示例输出：
4# loki-backend-0 2/2 Running 0 5m
5# loki-read-546cd5b67c-dsb84 1/1 Running 0 5m
6# loki-write-0 1/1 Running 0 5m

部署 Promtail（日志采集代理）

编写 Promtail 配置文件（promtail-values.yaml）

 1config:
 2 # 对接Loki的write服务（集群内服务名解析）
 3 clients:
 4 - url: http://loki-write:3100/loki/api/v1/push
 5 
 6 # 日志采集规则（采集K8s Pod日志）
 7 scrape_configs:
 8 - job_name: kubernetes-pods
 9 kubernetes_sd_configs:
10 - role: pod  # 基于Pod自动发现
11 relabel_configs:
12 # 添加命名空间标签
13 - source_labels: [__meta_kubernetes_pod_namespace]
14 action: replace
15 target_label: namespace
16 # 添加Pod名称标签
17 - source_labels: [__meta_kubernetes_pod_name]
18 action: replace
19 target_label: pod
20 # 添加容器名称标签
21 - source_labels: [__meta_kubernetes_pod_container_name]
22 action: replace
23 target_label: container
24 # 过滤掉无需采集的系统组件（可选，按需调整）
25 - source_labels: [__meta_kubernetes_pod_namespace]
26 regex: "kube-system|istio-system"
27 action: drop
28
29# 部署模式：DaemonSet（每个节点1个副本）
30daemonset:
31 enabled: true
32 extraArgs:
33 - --max-open-files=1000000  # 增加文件打开限制
34 # 健康检查配置
35 readinessProbe:
36 initialDelaySeconds: 60
37 timeoutSeconds: 10
38
39# 权限配置（解决日志目录读取权限问题）
40securityContext:
41 runAsUser: 0 # 以root用户运行
42 runAsGroup: 0
43 fsGroup: 0
44 allowPrivilegeEscalation: true
45 capabilities:
46 add:
47 - DAC_READ_SEARCH  # 增加目录读取权限
48
49# 资源配置（低资源占用）
50resources:
51 requests:
52 cpu: 50m
53 memory: 64Mi
54 limits:
55 cpu: 200m
56 memory: 256Mi
57
58# 禁用非必需组件
59serviceMonitor:
60 enabled: false
61prometheusRule:
62 enabled: false

部署 Promtail

1# 部署Promtail
2helm install promtail grafana/promtail -n monitoring \
3 -f promtail-values.yaml \
4 --version 5.36.0

验证 Promtail 部署

1# 查看Promtail Pod（每个节点1个副本，均需Running）
2kubectl get pods -n monitoring | grep promtail
3
4# 查看Promtail日志（确认无报错，有日志推送记录）
5PROMTAIL_POD=$(kubectl get pods -n monitoring -l app=promtail -o jsonpath='{.items[0].metadata.name}')
6kubectl logs -n monitoring $PROMTAIL_POD | grep "Successfully sent batch"
7# 示例输出：level=info ts=xxx caller=client.go:347 msg="Successfully sent batch"

最终验证

验证 GPU Operator & GPU metrics 是否正常

看 GPU Operator 相关 Pod：

1kubectl -n gpu-operator get pods
2kubectl -n gpu-operator get ds

通常会看到类似：

驱动 DaemonSet
Device Plugin DaemonSet
nvidia-dcgm-exporter 或类似名字的 DaemonSet

找到 DCGM Exporter 暴露出来的 Service：

1kubectl -n gpu-operator get svc

里面一般会有一个和 dcgm-exporter 类似名字的 Service，对应端口 9400（Prometheus 默认端口）。

本地 port-forward 看看 /metrics：

1# 换成你查到的 dcgm exporter 服务名
2kubectl -n gpu-operator port-forward svc/nvidia-dcgm-exporter 9400:9400
3
4# 打开一个新终端：
5curl http://127.0.0.1:9400/metrics | head

应该能看到类似：

1# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz).
2# TYPE DCGM_FI_DEV_SM_CLOCK gauge
3DCGM_FI_DEV_SM_CLOCK{gpu="0",UUID="GPU-xxxx"} 139
4...

说明 GPU 指标已经通过 DCGM Exporter 暴露出来了。

轻量级测试

1# 运行 GPU 测试 (显式申请 1 个 GPU)
2sudo kubectl run test-gpu-real \
3 -n model-serving \
4 --image=vllm/vllm-openai:latest \
5 --restart=Never \
6 --overrides='{"metadata": {"annotations": {"sidecar.istio.io/inject": "false"}}, "spec": {"containers": [{"name": "test-gpu-real", "image": "vllm/vllm-openai:latest", "command": ["nvidia-smi"], "resources": {"limits": {"nvidia.com/gpu": "1"}}}]}}'
7
8kubectl logs test-gpu-real -n model-serving

完整测试（triton + vllm）

有关 Namespace

注意 InferenceService 的 namespace 是：model-serving

为什么必须是 model-serving？

Istio 注入生效：我们之前只给 model-serving 命名空间打了 istio-injection=enabled 标签。只有部署在这个命名空间下的 Pod，才会自动拥有 Istio Sidecar（负责流量路由、Metrics 等）。
资源隔离：将业务模型与系统组件（如 gpu-operator, knative-serving）分开，是生产环境的最佳实践。

举例：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: qwen-7b-chat  # 你的服务名称
 5 namespace: model-serving  # 👈 这里必须写 model-serving
 6spec:
 7 predictor:
 8 model:
 9 modelFormat:
10 name: vllm  # 对应 ClusterServingRuntime 的名字
11 runtime: kserve-vllm  # 如果你有自定义 Runtime，这里指定名字
12 storageUri: "pvc://model-pvc/qwen-7b" # 或者 "s3://..."
13 resources:
14 requests:
15 cpu: "4"
16 memory: "16Gi"
17 nvidia.com/gpu: "1" # 👈 申请 1 张显卡
18 limits:
19 cpu: "4"
20 memory: "16Gi"
21 nvidia.com/gpu: "1"

即使 YAML 里写了 namespace，习惯上在 apply 时显式指定一下也是个好习惯（双重保险）：

1kubectl apply -f isvc-llm.yaml -n model-serving

五、完整调用链路

六、基于 Argo 的 CI / CD

GitHub: https://github.com/argoproj/argo-cd 官网：https://argoproj.github.io/

“

Argo = 一套专门给 Kubernetes 用的开源工具家族，用来做 CI / CD、工作流编排、GitOps 部署、灰度发布、事件驱动等，是 CNCF 下面的毕业项目

Argo 不是一个单一软件，而是一个 “工具矩阵”，主要包括四个子项目：

Argo Workflows

Kubernetes 原生的工作流 / 任务编排引擎
用 CRD（自定义资源）定义 Workflow，每个步骤跑在 Pod 里，非常适合 CI 流水线、数据处理、ML 训练等批处理任务

Argo CD

一个 GitOps 风格的持续交付工具
通过对比 Git 仓库里的 “期望状态” 和 K8s 集群中的 “实际状态”，自动同步和回滚应用，常用来管理大规模集群配置

Argo Rollouts

替代原生 Deployment 的 CRD
支持蓝绿发布、金丝雀发布，可以接入网关、监控指标做渐进式发布和自动回滚

Argo Events

做事件驱动自动化
支持各种事件源（Webhook、Kafka、S3 等），触发 Argo Workflows 或其他 K8s 资源，实现 event-driven CI / CD 或自动化任务

一句话：Argo = “围绕 Kubernetes 打造的一整套自动化 / GitOps / 发布 / 事件工具链”。

Argo 跟 Kubernetes 是什么关系？

“

Kubernetes 提供 “集群和基础设施”，Argo 提供 “在这个集群上自动化地干活的工具”。Argo 是 Kubernetes 最主流的 GitOps / Workflow 方案之一

CNCF 官方介绍中就把 Argo 定义为 “Kubernetes-native tools to run workflows, manage clusters, and do GitOps right”

运行环境层面：完全依赖 K8s

Argo 的所有组件（Controller、UI 等）都是以 Deployment / Pod 的形式部署在 Kubernetes 集群中。
Argo 的核心对象（Workflow、Rollout、EventSource、Application 等）都是 Kubernetes CRD。

职责分工：

Kubernetes 负责：调度 Pod、管理节点、网络、存储、基础监控。
Argo 负责：
把一堆任务编排成 “工作流” 并在 K8s 上跑（Workflows）
把 Git 仓库里的 YAML 自动同步到集群（CD & GitOps）
把发布过程做成可观测、可灰度控制的 rollouts（Rollouts）
把外部事件变成触发器（Events）

部署层级

所有文件都应该放到 git 让 Argo 负责吗？

不是的，这涉及到 “部署层级” 的问题。在云原生的 GitOps 实践中，我们将部署分为了两个截然不同的层级：

层级一：平台基础设施层

包含组件：Istio, Knative Serving, KServe, Cert-Manager, Nvidia Device Plugin 等。
特点：
变动低频：装好后很少动，顶多几个月升级一次版本。
全局影响：一旦挂了，所有模型全挂。
管理者：平台运维工程师 / SRE。
部署方式：通常使用 Helm Chart 或 Operator。

层级二：应用负载层

包含组件：InferenceService (模型), gateway (网关), ConfigMap (业务配置)。
特点：
变动高频：每天可能有新模型上线，或者修改版本、调整并发参数。
局部影响：配置错了只影响这一个模型。
管理者：算法工程师 / MLOps 工程师。
部署方式：YAML 文件 (InferenceService)。

所以目前来看，层级二的内容要以放到 git 中由 argo 管理 CD。层级一的也可以放到 git 中，但手动运维。

实践

Jenkins 本身是可以做全套的 CI + CD 的，但从我们推理服务部署这件事上来讲，CD (持续部署) 并不适合用 Jenkins，而适合用 Argo。Jenkins 在我们的这个场景下可以继续做它擅长的 CI (持续集成)，但想了想，没必要那么麻烦，全部用 Argo 结合 Git 就完全能搞定，而且很方便，不适合用 jenkins 再增加运维复杂度了。

ArgoCD 是云原生时代的王者（GitOps 流）

实操 for Triton（预演）

假设：

Git 仓库地址：git@github.com:your-name/ai-ops.git
S3 Bucket：my-ai-models
EKS 命名空间：ai-serving
自定义 Docker 镜像 –> 镜像仓库

第一阶段：基础设施与权限准备 (一次性工作)

这部分工作通常不需要经常变动，主要是为了打通 K8s 和 S3 的权限，以及准备 Git 仓库。

创建 Namespace (如果还没建)

1kubectl create namespace ai-serving

配置 S3 访问凭证 (Secrets) 注意：敏感信息不要直接上传到 Git。我们先用 kubectl 手动创建 Secret（或者使用 ExternalSecrets / SealedSecrets 等高级方案，但现在先用简单直接的方式）。

准备一个 s3-secret.yaml 在你本地（不要提交到 Git）：

 1apiVersion: v1
 2kind: Secret
 3metadata:
 4 name: my-s3-secret
 5 namespace: ai-serving
 6 annotations:
 7 serving.kserve.io/s3-endpoint: "s3.amazonaws.com" # AWS S3
 8 serving.kserve.io/s3-region: "us-east-1" # 你的 Region
 9type: Opaque
10stringData:
11 AWS_ACCESS_KEY_ID: "你的AK"
12 AWS_SECRET_ACCESS_KEY: "你的SK"

执行应用：

1kubectl apply -f s3-secret.yaml

在你的 ai-ops Git 仓库中，创建一个专门存放 ASR 部署文件的目录，例如 apps/asr-service/overlays/prod (如果是 Kustomize 结构) 或者直接 manifests/asr-service。

建议结构如下

1manifests/asr-service/
2├── service-account.yaml # 关联 Secret 的账号配置
3└── inference-service.yaml # 核心模型服务配置

编写 manifests/asr-service/service-account.yaml 并提交到 Git：

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4 name: sa-s3-access
5 namespace: ai-serving
6secrets:
7 - name: my-s3-secret # 引用刚才手动创建的 Secret

第二阶段：模型工件准备 (模型上线 / 更新时操作)

这个阶段是 “搬运工” 工作，把模型传上去，让 KServe 有东西可拉。

本地整理 Triton 结构

如之前所述，确保本地目录结构正确：

1simple-asr/
2├── config.pbtxt
3└── 1/
4 └── model.onnx

上传到 S3

使用 AWS CLI 或手动上传。

1# 假设上传到 bucket 的 triton-repo 目录下
2aws s3 cp --recursive simple-asr/ s3://my-ai-models/triton-repo/simple-asr/

验证：确保 s3://my-ai-models/triton-repo/simple-asr/config.pbtxt 存在。

第三阶段：Argo CD 配置与部署 (GitOps 核心)

这是让 Argo CD 接管部署的关键步骤。

编写 InferenceService 配置文件

在 Git 仓库的 manifests/asr-service/inference-service.yaml 中写入：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: asr-service
 5 namespace: ai-serving
 6 annotations:
 7 # 稍微改动这个字段可以触发 Argo 重新同步和 Pod 重启，常用于强制重新拉取模型
 8 serving.kserve.io/model-version: "v1-20231121" 
 9spec:
10 predictor:
11 serviceAccountName: sa-s3-access
12 model:
13 modelFormat:
14 name: onnx
15 runtime: kserve-tritonserver
16 storageUri: s3://my-ai-models/triton-repo/simple-asr
17 resources:
18 limits:
19 nvidia.com/gpu: 1

提交代码到 Git：

1git add .
2git commit -m "Add ASR inference service"
3git push

创建 Argo CD Application

你需要告诉 Argo CD：“去监控我的 Git 仓库，把东西部署到 EKS 里”。

你可以通过 Argo CD 的 Web UI 点击 “New App” 创建，或者写一个 YAML 文件（推荐 YAML 方式，这叫 App-of-Apps 模式）。

创建一个文件 asr-argocd-app.yaml (手动 apply 这个文件)：

 1apiVersion: argoproj.io/v1alpha1
 2kind: Application
 3metadata:
 4 name: asr-serving-app
 5 namespace: argocd
 6spec:
 7 project: default
 8 source:
 9 repoURL: 'https://github.com/your-name/ai-ops.git' # 你的 Git 地址
10 targetRevision: HEAD
11 path: manifests/asr-service  # 你的 YAML 所在目录
12 destination:
13 server: 'https://kubernetes.default.svc'
14 namespace: ai-serving
15 # 开启自动同步和自愈
16 syncPolicy:
17 automated:
18 prune: true # Git 里删了文件，K8s 里也删掉
19 selfHeal: true # 手动改了 K8s 配置，Argo 会强制改回来
20 syncOptions:
21 - CreateNamespace=true

执行：

1kubectl apply -f asr-argocd-app.yaml

第四阶段：验证与观察

一旦应用了上面的 Application YAML，奇迹就开始了：

观察 Argo CD UI：

你会看到 asr-serving-app 变成 Processing 状态。
它会画出一棵树：Application -> InferenceService -> Knative Configuration -> Revision -> Deployment -> Pod。
确保所有图标变绿（Healthy 和 Synced）。

观察 Pod 状态 (命令行)：

1kubectl get pods -n ai-serving

你会看到类似 asr-service-predictor-00001-deployment-xxx 的 Pod。

如果是 Init:0 / 1：正在运行 storage-initializer 下载 S3 模型。
如果是 Running：模型下载完毕，Triton 启动成功

日常开发流程

这套系统搭建好后，以后的日常工作流就是：

算法同学：训练新模型 -> 导出 ONNX -> 上传覆盖 S3 上的 model.onnx。
运维 / 算法同学：

修改 Git 里的 inference-service.yaml。
比如修改 annotations 里的 version: “v2” 或者修改资源配额。
git push。

Argo CD：自动检测到 Git 变化 -> 更新 K8s 资源 -> Knative 滚动更新 -> 新 Pod 拉取新模型 -> 流量平滑切换。

这就是最标准的 GitOps 模型部署流程。

实操 for vLLM（预演）

第一阶段：基础设施准备 (一次性工作)

因为 KServe 可能不知道怎么启动 vLLM，我们需要先在集群里注册一个 “说明书”，告诉 KServe：“当我说用 vllm 时，请拉取这个镜像并运行这个命令”。

创建 vLLM 的 ClusterServingRuntime

将以下内容保存为 vllm-runtime.yaml 并 kubectl apply -f（或者放入 ArgoCD 管理的基础设施 Git 仓库中）。

 1apiVersion: serving.kserve.io/v1alpha1
 2kind: ClusterServingRuntime
 3metadata:
 4 name: kserve-vllm
 5spec:
 6 annotations:
 7 prometheus.kserve.io/path: "/metrics"
 8 prometheus.kserve.io/port: "8000"
 9 containers:
10 - name: kserve-container
11 image: vllm/vllm-openai:latest  # 使用 vLLM 官方镜像
12 command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
13 args:
14 # 这里的 args 是默认值，会被 InferenceService 里的 args 覆盖或追加
15 - --port=8080
16 - --model=/mnt/models
17 - --served-model-name=default
18 - --trust-remote-code
19 env:
20 - name: HF_HOME
21 value: /tmp/hf
22 resources:
23 requests:
24 cpu: "4"
25 memory: "16Gi"
26 limits:
27 cpu: "8"
28 memory: "32Gi"

“

注意：vLLM 默认监听 8000，但 KServe 容器通常要求监听 8080，所以我们在 args 里强制指定 –port = 8080。

第二阶段：模型上传 (S3)

vLLM 不需要 Triton 那种 1 / model.onnx 的结构。它只需要标准的 HuggingFace 模型文件夹。

假设你要部署 Qwen2-7B：

本地准备

你需要把 HuggingFace 上的文件下载下来，目录结构大概长这样：

1Qwen2-7B/
2├── config.json
3├── tokenizer.json
4├── model-00001-of-00004.safetensors
5├── ...
6└── model.safetensors.index.json

上传 S3

1aws s3 cp --recursive Qwen2-7B/ s3://my-ai-models/llm/Qwen2-7B/

第三阶段：Argo CD 部署配置 (GitOps)

在 Git 仓库中（manifests/llm-service/），编写 inference-service.yaml。

这里有几个关键点需要注意：

runtime: 指定刚才创建的 kserve-vllm。
storageUri: 指向 S3 文件夹。KServe 会把这里面的所有文件下载到 Pod 的 /mnt/models 目录下。
args: 我们需要覆盖启动参数，告诉 vLLM 模型就在 /mnt/models。

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: qwen-llm
 5 namespace: ai-serving
 6 annotations:
 7 # LLM 启动很慢（加载权重需要时间），必须调大健康检查超时时间，否则会被 K8s 杀掉
 8 serving.knative.dev/progressDeadline: "20m" 
 9 
10 # 自动扩缩容配置 (LLM通常基于并发或请求数)
11 autoscaling.knative.dev/target: "5" 
12 autoscaling.knative.dev/minScale: "1" # 建议 LLM 至少保留1个，因为冷启动太慢了
13 autoscaling.knative.dev/maxScale: "3"
14spec:
15 predictor:
16 serviceAccountName: sa-s3-access # 别忘了 S3 权限账号
17 model:
18 modelFormat:
19 name: pytorch 
20 runtime: kserve-vllm # 对应 ClusterServingRuntime 的名字
21 
22 # KServe 会把这个 S3 路径下的内容下载到容器的 /mnt/models
23 storageUri: s3://my-ai-models/llm/Qwen2-7B
24 
25 # 核心参数配置
26 args:
27 - --model=/mnt/models  # 必填：指向下载好的模型路径
28 - --served-model-name=qwen # 服务名称，API调用时用到
29 - --gpu-memory-utilization=0.9 # 显存占用率
30 - --max-model-len=4096  # 上下文长度，防止 OOM
31 - --dtype=float16  # 或 bfloat16
32 
33 resources:
34 requests:
35 cpu: "8"
36 memory: "32Gi"
37 nvidia.com/gpu: 1 # 必须有 GPU
38 limits:
39 cpu: "16"
40 memory: "64Gi"
41 nvidia.com/gpu: 1
42 nodeSelector:
43 gpu-type: "A100" # 建议指定节点类型

提交到 Git，Argo CD 检测到后会自动同步。

创建 Argo CD Application

你可以通过 Argo CD 的 Web UI 点击 “New App” 创建，或者写一个 YAML 文件（推荐 YAML 方式，这叫 App-of-Apps 模式）。

创建一个文件 llm-argocd-app.yaml (手动 apply 这个文件)：

 1apiVersion: argoproj.io/v1alpha1
 2kind: Application
 3metadata:
 4 name: llm-serving-app  # 应用名称，要在 Argo 面板上显示的
 5 namespace: argocd  # ArgoCD 安装的命名空间
 6spec:
 7 project: default
 8 source:
 9 repoURL: 'https://github.com/your-name/ai-ops.git' # 你的 Git 仓库
10 targetRevision: HEAD
11 path: manifests/llm-service  # ✅ 关键点：指向存放 vLLM InferenceService 的目录
12 destination:
13 server: 'https://kubernetes.default.svc'
14 namespace: ai-serving  # 部署的目标命名空间
15 # 启用自动同步，Git 变了 K8s 自动变
16 syncPolicy:
17 automated:
18 prune: true # Git 里删了，K8s 也删
19 selfHeal: true # K8s 里被改了，强制还原回 Git 的状态
20 syncOptions:
21 - CreateNamespace=true # 如果 ai-serving 命名空间不存在，自动创建

执行：

1kubectl apply -f llm-argocd-app.yaml

第四阶段：部署后的验证与调用

vLLM 启动成功后，它提供的是 OpenAI Compatible API。这意味着你可以直接用 OpenAI 的 SDK 或者 curl 来调用，这比 Triton 的 gRPC 接口对开发者更友好。

验证 Pod 状态

1kubectl get pods -n ai-serving
2# 等待状态变为 Running (可能需要几分钟下载模型和加载权重)
3kubectl logs -f <pod-name> -c kserve-container -n ai-serving
4# 看到日志显示 "Uvicorn running on http://0.0.0.0:8080" 即成功

调用测试 (在集群内部或通过 Ingress)

获取服务的 URL

1kubectl get isvc qwen-llm -n ai-serving
2# 假设 URL 是 http://qwen-llm.ai-serving.svc.cluster.local

发送请求（完全兼容 OpenAI 格式）：

 1curl http://qwen-llm.ai-serving.svc.cluster.local/v1/chat/completions \
 2 -H "Content-Type: application/json" \
 3 -d '{
 4 "model": "qwen",
 5 "messages": [
 6 {"role": "system", "content": "You are a helpful assistant."},
 7 {"role": "user", "content": "你好，介绍一下你自己。"}
 8 ],
 9 "max_tokens": 100
10 }'

vLLM 流程的关键 Checklist

ClusterServingRuntime: 你的集群里如果没有 kserve-vllm 定义，第一步就会报错，必须先加这个 CRD。
Timeouts: LLM 动辄 20GB+，下载 + 加载显存需要很久。一定要在 annotations 里设置 progressDeadline 为 20m 或更长，否则 Knative 会以为部署失败并回滚。
Arguments: 必须通过 args 显式指定 –model=/mnt/models，因为这是 KServe storageUri 下载的目标路径。
Resources: 显存和内存给够，否则 vLLM 会报 OOM（Out Of Memory）并 CrashLoopBackOff。

这套流程结合 ArgoCD 后，以后更新 LLM 版本（比如从 Qwen2 换到 Qwen2.5），你只需要：

上传新模型到 S3 的新目录。
修改 Git 里的 storageUri。
ArgoCD 自动同步，Knative 会等待新 Pod 里的 vLLM 完全加载好权重后，才切断旧 Pod 的流量。

七、如何衡量平台是否成功？

一个优秀的模型服务平台，其核心指标应该覆盖性能、成本、稳定性几个维度。

维度一：性能与延迟 (Performance & Latency) - “我们的服务快不快？”

端到端延迟 (End-to-End Latency) - P95 / P99

是什么？从业务应用发出 API 请求，到收到完整响应的总时间。
为什么重要？这是衡量用户体验的黄金标准。我们通常关注 P95（95% 的请求都快于此值）和 P99，因为平均值会掩盖那些最慢的、最影响用户的请求。
如何衡量？从 Istio Gateway 或 Prometheus 中间件获取。

首 Token 时间 (Time to First Token - TTFT) - (LLM 专属)

是什么？对于生成式模型，从发出请求到收到第一个有意义的 token 所需的时间。
为什么重要？这是衡量 LLM 服务 “感知响应速度” 的最关键指标。一个低 TTFT 的模型会让用户感觉 “反应很快”，即使生成全文总时间较长。
如何衡量？需要在客户端或 Transformer 中进行定制化测量

每输出 Token 时间 (Time Per Output Token - TPOT) - (LLM 专属)

是什么？生成每个后续 token 的平均时间。它是 (总时间 - TTFT) / (总 token 数 - 1)。
为什么重要？这是衡量 LLM “生成速度” 的核心指标。一个低的 TPOT 意味着模型的 “吐字” 速度很快，用户体验流畅。
如何衡量？客户端或 Transformer 中计算。

吞吐量 (Throughput)

是什么？单位时间内平台能成功处理的请求数。通常用 RPS (Requests Per Second) 或 QPS (Queries Per Second) 表示。
对于 LLM，一个更有意义的指标可能是输出 Tokens/秒 (Output Tokens/Second)，因为它综合了并发处理能力和生成速度。
为什么重要？这是衡量平台容量和处理能力的上限。

维度二：成本与效率 (Cost & Efficiency) - “我们的钱花得值不值？”

GPU 利用率 (GPU Utilization - Compute)

是什么？ GPU 计算核心在单位时间内的繁忙程度百分比。
为什么重要？这是衡量 “GPU 是否在干活” 的首要指标。一个持续低于 20% 的利用率可能意味着巨大的资源浪费。
如何衡量？通过 NVIDIA DCGM Exporter 在 Prometheus 中采集。

GPU 显存利用率 (GPU Memory Utilization)

是什么？ GPU 显存被占用的百分比。
为什么重要？很多模型（尤其是 LLM）可能计算量不大，但会占用海量显存。高显存占用会限制单卡能部署的模型数量。这是成本优化的另一个关键。
如何衡量？通过 NVIDIA DCGM Exporter 采集。

闲置实例数 / 缩容至零频率 (Scale-to-Zero Metrics)

是什么？平台上有多少模型服务实例处于 0 副本状态，以及它们进入和退出 0 副本状态的频率。
为什么重要？直接体现了 KServe + Knative Serverless 架构带来的成本节省效果。
如何衡量？从 Knative 的监控指标中获取。

冷启动延迟 (Cold Start Latency)

是什么？当一个服务从 0 副本状态接收到第一个请求时，从开始拉起 Pod 到成功响应请求的总时间。
为什么重要？这是 Serverless 模式为了节省成本而付出的性能代价。你需要监控并优化它，确保它在可接受的范围内。
如何衡量？结合 Knative 指标和应用日志进行分析。

维度三：稳定性与可用性 (Stability & Availability)- “我们的服务稳不稳？”

服务可用性 (Availability)

是什么？在规定时间内，服务能够正常响应的请求比例。通常目标是 99.9% 或 99.99%。
为什么重要？这是衡量服务可靠性的最终标准。
如何衡量？ (成功请求数 / 总请求数) * 100%。

错误率 (Error Rate)

是什么？返回 5xx（服务器错误）状态码的请求比例。
为什么重要？错误率的飙升是服务出现严重问题的最直接信号。需要设置告警。
如何衡量？从 Istio Gateway 或 Prometheus 中间件获取。

Pod 重启次数 (Pod Restart Count)

是什么？模型服务 Pod 的重启次数。
为什么重要？频繁的重启（特别是 CrashLoopBackOff 状态）表明代码存在 Bug、内存溢出（OOM Killed）或配置错误。
如何衡量？从 Kubernetes API 直接获取。

短期看，最重要的指标有这几个：

端到端延迟 (End-to-End Latency)
首 Token 时间 (Time to First Token - TTFT)
吞吐量 (Throughput)
GPU 利用率
服务可用性

长期看其实还要加上模型效果指标，量化 “准确率” 与 “生成质量”。

今日 AI 情报

Sun, 09 Nov 2025 02:02:43 +0000

题图：伊丽莎白女王工程奖获奖的 AI 界群星

打败GPT5的Kimi K2 Thinking，真就只会写代码吗？

通过多种场景测试评估Kimi K2 Thinking的表现，包括编程、3D模拟、创意写作、复杂推理和架构对比分析

打败GPT5的Kimi K2 Thinking，真就只会写代码吗？2. Artificial Analysis评测新鲜出炉：Kimi K2 thinking位居世界第二，开源第一

Artificial Analysis评测显示Kimi K2 Thinking模型在智能体任务中表现突出，以67分位居世界第二、开源第一，但存在生成冗长和延迟问题

Artificial Analysis评测新鲜出炉：Kimi K2 thinking位居世界第二，开源第一

解析！大模型中的ScalingLaw的概念、推导以及反ScalingLaw的场景

全面详细介绍大模型ScalingLaw的概念、数学推导、实际应用场景及反ScalingLaw现象，为大模型训练提供理论指导

解析！大模型中的ScalingLaw的概念、推导以及反ScalingLaw的场景

LLM首次达到人类语言专家水平！OpenAI o1拿下拆解句法、识别歧义、推理音律

研究表明OpenAI o1模型在处理语言递归结构、识别句法歧义和音韵推理等方面表现出接近人类语言学专家的能力

LLM首次达到人类语言专家水平！OpenAI o1拿下拆解句法、识别歧义、推理音律

SimKO：缓解RLVR训练中的概率过度集中，优化pass@K性能

介绍SimKO算法如何通过非对称梯度调节解决RLVR训练中的概率过度集中问题，优化大语言模型在数学推理任务上的pass@K性能

SimKO：缓解RLVR训练中的概率过度集中，优化pass@K性能

6.4万star的开源智能体框架全面重构！OpenHands重大升级，叫板OpenAI和谷歌

详细介绍了OpenHands V1智能体框架的架构重构，包括四项设计原则和技术特性，以及与OpenAI和Google产品的比较和性能评估

6.4万star的开源智能体框架全面重构！OpenHands重大升级，叫板OpenAI和谷歌

Building the First Agentic Government with Ukraine

介绍ElevenLabs与乌克兰政府合作建设首个代理型政府的伙伴关系，将AI应用于公共服务

https://elevenlabs.io/blog/building-the-first-agentic-government-with-ukraine

ICCV涌现自动驾驶新范式：统一世界模型VLA，用训练闭环迈向L4

文章深入分析理想汽车在ICCV上展示的统一世界模型VLA，介绍了自动驾驶从数据闭环到训练闭环的技术进化，以及理想在AI领域的技术布局

https://www.qbitai.com/2025/11/350282.html

机器人训练，北京男大有了技能玩法

北京通用人工智能研究院研究团队开发了COLA方法，实现了人形机器人仅依靠本体感知而无需外部传感器就能与人类协作搬运物体的技术突破

https://www.qbitai.com/2025/11/350301.html

LLM强化学习新框架！UCSD多智能体训练框架让LLM工具调用能力暴增5.8倍

研究者提出通用多智能体强化学习框架PettingLLMs，通过树状采样与角色化奖励机制，显著提升LLM工具调用能力和多智能体协作效果

https://www.qbitai.com/2025/11/350331.html

当“刷分”不再性感：为什么说姚顺雨的“AI下半场”是我们每个人的必修课？

Sun, 14 Sep 2025 09:03:45 +0000

引言

本文我将对 2025 年上半年在技术社区引发大量讨论与转引的一篇名为《The Second Half》（AI 的下半场）著名博客进行介绍、翻译与分析，希望通过我的介绍和分析能够让各位伙伴对 AI 领域在宏观叙事上有个清晰的了解。以便在今后的学习和研究中有更好的定位和方向。

作者简介

概览

姚顺雨（Shunyu Yao）

姚顺雨是近年“语言智能体（Language Agents）”方向的代表性研究者之一，因提出 ReAct、参与 Tree of Thoughts (ToT)、WebShop、SWE-bench / SWE-agent、τ-bench 等工作受到学界与产业关注；在 2025 年以《The Second Half》一文提出“AI 的下半场应从‘解决问题’转向‘定义问题’，评估将比训练更重要”的观点。其个人主页长期自述为“研究智能体的 OpenAI 研究员”。

教育与经历

●中学阶段获 NOI 信息学银牌、安徽省理科高考第 3 名

●本科：清华大学交叉信息研究院“姚班”（学生时期就读于姚班，多场高校活动与官方简介均有明确表述）。在校期间担任“姚班学生联合会主席”、清华说唱社联合创始人。

●博士：普林斯顿大学计算机系（导师 Karthik Narasimhan）。博士阶段获普林斯顿研究生院 Harold W. Dodds Fellowship；其博士论文主题为 Language Agents: From Next-Token Prediction to Digital Automation。

●实习/合作经历（学生时期）：多场讲座与高校活动页称其曾在 Google、Microsoft、MIT 等从事研究与合作。

代表性研究与贡献

●ReAct（Reason + Act）：提出让大模型在“推理轨迹”与“动作”之间交替，从而一边思考一边使用工具/检索/交互，ICLR 2023。此范式被广泛用作后续智能体系统的基础能力模块。arXiv

●Tree of Thoughts（ToT）：将“多路径思维”引入复杂问题求解的推理过程中，NeurIPS 2023。NeurIPS Proceedings

●WebShop：一个规模化网页购物交互环境（NeurIPS 2022），推动语言智能体在真实网页环境中的训练与评估。NeurIPS Papers

●SWE-bench（ICLR 2024 Oral）/ SWE-agent（NeurIPS 2024）：以前者把“修真实 GitHub issue”作为评测单位，后者设计“Agent-Computer Interface”让代理能像人一样使用电脑完成工程任务，推动贴近实际的软件工程评测与系统化落地。OpenReview NeurIPS Proceedings

●τ-bench（ICLR 2025）：强调在真实领域的规则与用户交互下评测语言智能体（工具-代理-用户三方互动），契合其“评估更重要”的研究取向。OpenReview

近期动态（2025 年 9 月）

●已从 OpenAI 离职：彭博社报道称 OpenAI 已确认其离职，但未说明去向。

●去向传闻与澄清：有媒体称其被腾讯聘用；与此同时，腾讯方面辟谣了“上亿年薪”等细节，并未明确确认其入职与否。因此目前去向仍存不确定性。

原文和翻译

原文

https://ysymyth.github.io/The-Second-Half/

翻译

AI 的下半场

一句话总结：我们正处于人工智能（AI）的中场休息时间。

几十年来，人工智能的发展主要围绕着开发新的训练方法和模型。这一策略卓有成效：从在国际象棋和围棋上击败世界冠军，到在 SAT（学术能力评估测试）和律师资格考试中超越大多数人类，再到斩获国际数学奥林匹克（IMO）和国际信息学奥林匹克（IOI）金牌。在这些载入史册的里程碑——深蓝（DeepBlue）、AlphaGo、GPT-4 及 o 系统模型——背后，是 AI 方法论的根本性创新：搜索、深度强化学习（deep RL）、规模化（scaling）和推理（reasoning）。一切都在随着时间不断进步。

那么，现在究竟有何不同？

简而言之：强化学习（RL）终于奏效了。更准确地说：强化学习终于具备了泛化能力。在经历了数次重要的弯路并累积了一系列里程碑之后，我们终于找到了一个行之有效的“秘方”，能够利用语言和推理解决广泛的强化学习任务。哪怕在一年前，如果你告诉大多数 AI 研究者，同一个“秘方”能够应对软件工程、创意写作、IMO 级别的数学、键鼠操作以及长篇问答等任务，他们可能会觉得你在痴人说梦。这些任务中的任何一个都极其困难，许多研究者穷尽整个博士生涯也只能专注于其中一个狭窄的领域。

然而，这一切确实发生了

那么，接下来会发生什么？AI 的下半场——从现在开始——将把焦点从解决问题转向定义问题。在这个新时代，评估（evaluation）将比训练更加重要。我们将不再仅仅追问“我们能否训练一个模型来解决 X 问题？”，而是要问“我们究竟应该训练 AI 去做什么，以及如何衡量真正的进展？” 要在下半场脱颖而出，我们需要及时转变思维模式和技能组合，或许要更像一名产品经理。

上半场

要理解上半场，只需看看它的赢家。你认为迄今为止最具影响力的 AI 论文是哪些？

我在斯坦福大学的 224N 课程上做过这个小调查，答案不出所料：Transformer、AlexNet、GPT-3 等等。这些论文有何共同之处？它们都提出了某些根本性的突破，用以训练出更好的模型。同时，它们也通过在某些基准测试（benchmarks）上展示出（显著的）性能提升而成功发表。

然而，这背后还有一个潜在的共性：这些“赢家”都是训练方法或模型，而非基准测试或任务。即便是被认为最具影响力的基准测试 ImageNet，其引用量也不及 AlexNet 的三分之一。方法与基准测试之间的这种反差在其他领域更为悬殊——例如，Transformer 模型主要使用的基准是 WMT'14，其相关研讨会报告的引用量约为 1,300 次，而 Transformer 论文的引用量已超过 160,000 次。

这揭示了上半场的游戏规则：专注于构建新的模型和方法，而评估和基准测试则处于次要地位（尽管它们对于维持论文发表体系的运转是必需的）。

为什么会这样？一个重要原因是，在 AI 的上半场，方法比任务更困难，也更激动人心。从零开始创造一种新算法或模型架构——例如反向传播算法、卷积网络（AlexNet）或 GPT-3 中使用的 Transformer——需要非凡的洞察力和工程能力。相比之下，为 AI 定义任务则往往显得更为直接：我们只是将人类已有的任务（如翻译、图像识别或国际象棋）转化为基准测试。这其中并不需要太多的洞察力，甚至工程量也不大。

此外，方法通常比单个任务更具通用性和广泛适用性，这使其价值尤为突出。例如，Transformer 架构最终推动了计算机视觉（CV）、自然语言处理（NLP）、强化学习（RL）等多个领域的进步，其影响远远超出了最初证明其有效性的那个单一数据集（WMT'14 翻译任务）。一个优秀的新方法之所以能够提升多个不同基准测试的性能，正是因为它既简单又通用，其影响力因此超越了单个任务的范畴。

这场游戏持续了几十年，催生了改变世界的思想和突破，其成果体现在各个领域基准测试性能的不断提升上。那么，为何游戏规则会发生改变？因为这些思想和突破的积累，最终在创造一个解决任务的有效“秘方”上引发了质变。

那个秘方

这个“秘方”是什么？不出所料，其配方包括：大规模语言预训练、规模化（数据和算力），以及推理与行动（reasoning and acting） 的理念。这些词听起来可能像是你在旧金山每天都能听到的流行语，但为何称之为“秘方”？

我们可以通过强化学习（RL）的视角来理解这一点。RL 常被视为 AI 的“终局之战”——毕竟，从理论上讲，RL 保证能赢得游戏；从经验上看，也很难想象任何超人系统（如 AlphaGo）的诞生能脱离 RL。

在 RL 中，有三个关键组成部分：算法（algorithm）、环境（environment）和先验知识（priors）。长期以来，RL 研究者主要关注算法——即智能体学习方式的智力核心（例如 REINFORCE、DQN、TD-learning、Actor-Critic、PPO、TRPO 等）——而将环境和先验知识视为固定或次要的。例如，Sutton 和 Barto 的经典教科书通篇都在讲算法，几乎没有涉及环境或先验知识。

然而，在深度强化学习时代，环境在经验层面上的重要性变得显而易见：一个算法的性能往往高度依赖于其开发和测试所处的特定环境。如果忽略环境，你可能会构建出一个只在“玩具”环境中表现优异的“最优”算法。那么，我们为何不先弄清楚我们真正想解决的环境是什么，然后再寻找最适合该环境的算法呢？

这正是 OpenAI 最初的计划。它创建了 Gym，一个包含各种游戏的标准 RL 环境，随后又启动了 World of Bits 和 Universe 项目，试图将整个互联网或计算机变成一个游戏。这个计划听起来不错，不是吗？一旦我们将所有数字世界都转化为一个环境，再用聪明的 RL 算法去解决它，我们就拥有了数字化的通用人工智能（AGI）。

计划虽好，但并非完全奏效。OpenAI 在这条道路上取得了巨大进展，利用 RL 解决了 Dota 游戏、机械手控制等问题。但它从未接近解决计算机通用操作或网页浏览的难题，并且在一个领域有效的 RL 智能体也无法迁移到另一个领域。有些东西缺失了。

直到 GPT-2 或 GPT-3 出现之后，我们才发现，那块缺失的拼图是先验知识。你需要强大的语言预训练来将通用的常识和语言知识“蒸馏”到模型中，这些模型随后可以被微调，成为网络（WebGPT）或聊天（ChatGPT）智能体（并改变世界）。事实证明，RL 最重要的部分，或许既不是 RL 算法，也不是环境，而是先验知识——而这些先验知识的获取方式可以与 RL 毫无关系。

语言预训练为聊天任务创造了良好的先验知识，但对于控制计算机或玩视频游戏，效果却不尽相同。为什么？因为这些领域与互联网文本的分布相去甚远，简单地在这些领域上进行监督微调（SFT）或强化学习，其泛化能力很差。我在 2019 年就注意到了这个问题，当时 GPT-2 刚发布，我基于它进行 SFT/RL 来解决文字冒险游戏——由此诞生的 CALM 是世界上第一个基于预训练语言模型构建的智能体。但这个智能体需要数百万步的 RL 训练才能在一个游戏中取得进展，而且无法迁移到新的游戏。尽管这完全符合 RL 的特性，对 RL 研究者来说也见怪不怪，但我却觉得很奇怪，因为我们人类可以轻松地玩一个新游戏，并且在零样本（zero-shot）的情况下表现得好得多。然后，我迎来了人生中最早的“顿悟时刻”之一——我们之所以能够泛化，是因为我们可以选择做的不仅仅是“走向 2 号柜子”、“用 1 号钥匙打开 3 号宝箱”或“用剑杀死地牢里的怪物”，我们还可以选择去思考，比如：“地牢很危险，我需要一把武器来战斗。这里没有现成的武器，也许我需要在锁着的箱子或宝箱里找找看。3 号宝箱在 2 号柜子里，我先去那里把它打开。”

思考，或者说推理（reasoning），是一种奇特的行动——它不直接影响外部世界，但推理的空间却是开放式的、组合爆炸式的无限——你可以思考一个词、一个句子、一整段话，甚至是 10000 个随机的英文单词，而你周围的世界并不会立即发生改变。在经典的 RL 理论中，这简直是一场灾难，会让决策变得不可能。想象一下，你需要在两个盒子中选择一个，其中一个装有 100 万美元，另一个是空的。你的期望收益是 50 万美元。现在，想象我加入了无限个空盒子。你的期望收益就变成了零。但是，通过将推理加入任何 RL 环境的行动空间，我们利用了语言预训练的先验知识来实现泛化，并且能够在测试时为不同的决策灵活分配计算资源。这是一件非常神奇的事情，很抱歉我在这里没能完全解释清楚，或许我需要再写一篇博客来专门阐述。欢迎阅读 ReAct 论文来了解关于智能体推理的最初构想，并感受我当时的一些想法。目前，我的直观解释是：尽管你加入了无限个空盒子，但你在过往的各种游戏中已经见过它们无数次，选择这些空盒子的经验能让你在任何给定的游戏中更好地选中有钱的那个盒子。我的抽象解释则是：语言通过智能体中的推理来实现泛化。

一旦我们拥有了正确的 RL 先验知识（语言预训练）和 RL 环境（将语言推理作为行动加入），事实证明 RL 算法本身反而是最微不足道的部分。于是，我们看到了 o-系列、R1、Deep Research 的计算机操作智能体，以及未来更多类似的模型。这是多么具有讽刺意味的转折！长期以来，RL 研究者对算法的关心远超环境，更没有人关注过先验知识——所有的 RL 实验基本上都是从零开始。但我们花了几十年的弯路才意识到，也许我们优先级的排序本应完全颠倒。

但正如史蒂夫·乔布斯所说：你无法预见未来的点滴如何串联，只有在回顾过去时，才能将它们连接起来。

下半场

这个“秘方”正在彻底改变游戏规则。回顾一下上半场的游戏：

●我们开发新颖的训练方法或模型来提升基准测试的性能。

●我们创造更难的基准测试，然后继续这个循环。

这场游戏正在被打破，因为：

●这个“秘方”已经将提升基准测试性能的过程标准化和工业化了，不再需要太多新的思想。随着这个“秘方”的规模化和泛化能力越来越强，你为某个特定任务设计的新方法可能只能带来 5% 的提升，而下一个 o-系列模型即便没有专门针对这个任务，也能带来 30% 的提升。

●即使我们创造出更难的基准测试，它们也很快（而且越来越快地）被这个“秘方”所解决。我的同事 Jason Wei 制作了一张精美的图表，很好地展示了这一趋势。

那么，下半场还剩下什么可玩的？如果不再需要新颖的方法，而更难的基准测试也只会被越来越快地解决，我们该做什么？

我认为，我们应该从根本上重新思考评估。这不仅仅意味着创造更新、更难的基准测试，而是要从根本上质疑现有的评估设定，并创造新的设定，从而迫使我们去发明超越现有“秘方”的新方法。这很困难，因为人类有惯性，很少会去质疑基本的假设——你只是想当然地接受它们，而没有意识到它们是假设，而非定律。

为了解释这种惯性，假设你发明了历史上最成功的评估方法之一，它基于人类的考试。这在 2021 年是一个极其大胆的想法，但 3 年后，这个方向已经饱和了。你会怎么做？很可能你会去创造一个更难的考试。或者，假设你解决了简单的编程任务。你会怎么做？很可能你会去找更难的编程任务，直到达到 IOI 金牌的水平。

惯性是人之常情，但问题在于：AI 已经在国际象棋和围棋上击败了世界冠军，在 SAT 和律师资格考试中超越了大多数人类，并在 IOI 和 IMO 中达到了金牌水平。但世界并没有因此发生太大改变，至少从经济和 GDP 的角度来看是这样。

我称之为效用问题（utility problem），并认为这是 AI 领域最重要的问题。

或许我们很快就能解决这个效用问题，或许不能。但无论如何，这个问题的根源可能简单得令人迷惑：我们的评估设定在很多基本方面都与真实世界的设定不同。举两个例子：

1.评估“应该”是自动运行的，所以通常一个智能体接收一个任务输入，自主完成任务，然后获得一个任务奖励。但在现实中，智能体在整个任务过程中必须与人类互动——你不会只给客服发一条超长的信息，然后等 10 分钟，就指望收到一个详尽的回复解决所有问题。通过质疑这种设定，新的基准测试被发明出来，它们要么将真实人类纳入评估环路（如 Chatbot Arena），要么使用用户模拟（如 tau-bench）。

2.评估“应该”是独立同分布（i.i.d.）的。如果你有一个包含 500 个任务的测试集，你会独立地运行每个任务，然后对任务指标取平均，得到一个总指标。但在现实中，你是按顺序解决任务，而非并行。一位谷歌的软件工程师随着对代码库越来越熟悉，解决问题的效率会越来越高，但一个软件工程师智能体在同一个代码库中解决多个问题时，却无法获得这种熟悉度。我们显然需要长时记忆的方法（这类方法也确实存在），但学术界没有合适的基准测试来证明这种需求的必要性，甚至没有足够的勇气去质疑作为机器学习基础的 i.i.d. 假设。

这些假设“一直”以来就是如此，在 AI 的上半场，基于这些假设来开发基准测试并没有问题，因为当智能水平较低时，提升智能通常也能提升效用。但现在，通用的“秘方”在这些假设下几乎是万能的。因此，下半场的新游戏规则是：

●我们开发新颖的、旨在提升现实世界效用的评估设定或任务。

●我们用现有的“秘方”来解决它们，或者通过增加新的组件来增强“秘方”。然后继续这个循环。

这场游戏很困难，因为它很陌生。但它也令人兴奋。上半场的玩家解决的是视频游戏和考试，而下半场的玩家则有机会通过将智能转化为有用的产品，来创建价值数十亿甚至数万亿美元的公司。上半场充满了渐进式的方法和模型，而下半场在某种程度上会过滤掉它们。通用的“秘方”会轻易碾压你的渐进式方法，除非你创造出能打破这个“秘方”的新假设。那时，你才能做出真正改变游戏规则的研究。

欢迎来到下半场！

深度解析

《The Second Half》提示了我们所处的人工智能时代的一个根本性的范式转移

对“上半场”的深刻反思

上半场的游戏哲学：“更好”等于“更高分”

上半场的竞争逻辑是极其纯粹且清晰的：通过创造更优秀的模型和算法，在公认的、标准化的基准测试（Benchmark）上取得更高的分数。无论是计算机视觉领域的 ImageNet 挑战赛，还是自然语言处理领域的 GLUE、SuperGLUE 排行榜，整个学术界和工业界都被卷入了一场围绕“SOTA”（State-of-the-Art）的军备竞赛。

这种模式的底层信仰是：智能本身是线性可扩展的，只要模型在基准测试上的表现越好，它在真实世界中的应用潜力就越大。这在很长一段时间内是正确的。AlexNet 在 ImageNet 上的胜利，直接催生了计算机视觉的黄金十年；Transformer 架构的提出，则奠定了整个大语言模型时代的基础。我们专注于“造锤子”，因为市场上有无数显而易见的“钉子”等着我们去敲。

成功的“惯性”与“范式之疲”的显现

然而，当一个范式取得巨大成功后，它会产生巨大的惯性，这种惯性会掩盖其底层逻辑的悄然变化。我们正面临着“上半场范式”的系统性疲劳，其症状体现在三个方面：

●症状一：能力的商品化与竞争的同质化。“通用秘方”（大规模预训练 + 规模化 + 推理/行动）的出现，是一个颠覆性的事件。它意味着，世界顶级的感知、生成和基础推理能力，正在迅速地从少数巨头的“独门秘籍”变为一种类似水和电的、可按需取用的“基础设施”。无论是通过 API 调用 OpenAI 的模型，还是利用强大的开源模型（如 Llama 系列），任何一个具备基本工程能力的公司，都能站在巨人的肩膀上。这直接导致，单纯依靠基础模型能力本身来构建的护城河，其水位正在以肉眼可见的速度下降。我们正进入一个“后模型时代”，竞争的焦点必然从模型本身转移到更高维度的层面。

●症状二：“效用问题”（The Utility Problem）的尖锐化。这是《The Second Half》一文最核心、也最深刻的洞察。我们看到无数令人惊叹的 Demo：AI 在 SAT、律师资格考试、甚至奥数竞赛中击败人类。但当我们把目光投向宏观经济指标，如劳动生产率的增长，却发现其影响远未达到预期的“奇点”时刻。在企业内部，我们同样能感受到这种“演示与部署之间的鸿沟” 。一个能在测试集上达到 95% 准确率的模型，部署到真实、混乱的业务流程中时，其表现可能会断崖式下跌。这种“高分低能”的现象，深刻地揭示了我们上半场评估体系的根本性缺陷：它奖励的是在无菌实验室里解决抽象问题的能力，而非在真实世界中创造可靠价值的能力。

●症状三：边际成本的急剧攀升与创新动力的衰减。追逐 SOTA 的游戏，其成本正在变得越来越昂贵。将一个模型的性能从 90% 提升到 91%，可能需要消耗双倍的算力和数据。这种投入产出比的急剧下降，使得除了少数资源雄厚的玩家外，大多数公司都无法也不应参与这场“军备竞赛”。更危险的是，对“刷分”的过度关注，可能会扼杀掉那些无法立即在现有基准上体现价值、但却可能开辟全新路径的颠覆性创新。

下半场的本质：在不确定性世界中定义价值

下半场的核心特征是“发散” 。

●问题的本质是不确定的：我们不再有一个清晰的数学目标，而是要解决一个模糊的商业/用户问题。例如，“提升用户对我们产品的满意度”、“降低新员工的培训成本”。这些问题无法用一个简单的分数来衡量。

●环境是动态和复杂的：真实世界是连续的、充满互动的、非结构化的。用户有记忆，任务之间相互关联，一个错误的决策会带来长期的负面影响。

●成功的关键是“定义问题和评价体系”：当所有玩家都用上了相似的“万能锤子”（强大的基础模型），胜负手就不再是锤子本身，而是“你知道应该在哪堵墙上凿个洞，以及你知道怎么才算凿好了” 。

○在哪凿洞？ —— 定义问题（Problem Definition）。这需要深入理解业务场景、用户痛点。

○怎么算凿好了？ —— 构建评估（Evaluation Design）。这是下半场的核心竞争力。如何设计一套能够真实反映“用户价值”的评估体系，决定了你的 AI 能否在正确的方向上迭代。

构建“下半场”的胜利引擎

如果说上半场的核心产物是“模型”，那么下半场的核心产物则必然是“系统”——一个能够将通用智能与我们独特的业务场景、数据、流程深度融合的智能体（Agent）系统。我想详细阐述这个系统的架构哲学，它远比“LLM+Prompt”复杂，也坚固得多。

认知核心

这是 Agent 的 “大脑”，通常由一个或多个 LLM/VLM 构成。我们的战略不应是重复造轮子，而是构建一个可插拔、可路由的模型层，能根据任务的成本和复杂度，智能地选择最优模型。它至少要包括以下两部分：

1.模型抽象与路由层：这是架构的基石。我们需要一个统一的接口，能够屏蔽掉不同模型（OpenAI, Anthropic, Google, 开源模型, 自研小模型）的差异。能够根据任务的复杂度、延迟要求、成本预算、安全等级，动态地将请求分发给最合适的模型。例如，一次简单的情感分类任务应该由一个本地化的、低成本的小模型处理；而一次需要复杂多步规划的请求，则路由到最强大的大模型。

2.提示工程平台化（PromptOps）：Prompt 是我们与 AI 交流的语言，它不应是散落在代码各处的“魔法字符串”。我们需要一个企业级的 PromptOps 平台，对 Prompt 进行版本化管理、A/B 测试、自动化评估和持续优化。这个平台将是我们沉淀“人机交互知识”的核心资产。

记忆系统

一个没有记忆的 Agent，永远只是一个强大的、但健忘的工具。记忆系统是 Agent 实现个性化、持续进化的关键，也是构建数据飞轮的核心。

●短期工作记忆（Working Memory）：这是 Agent 处理当前任务的“内存”。它需要高效地管理对话历史、任务中间状态、工具调用结果等。挑战在于如何在保持长上下文的同时，有效控制成本和延迟。

●长期情景记忆（Long-Term Episodic Memory）：这是 Agent 的“人生经历”。每一次成功的交互、每一次失败的尝试、每一个用户的特定偏好，都应该被向量化，并存入一个可供检索的长期记忆库。当 Agent 遇到新任务时，它能“回忆”起过去处理类似情况的经验，从而做出更优的决策。

●长期语义/程序记忆（Long-Term Semantic/Procedural Memory）：这是 Agent 的“知识库”和“技能库”。前者存储了我们公司独有的领域知识（如产品文档、行业报告），后者则存储了完成特定任务的标准化流程（SOPs）。这确保了 Agent 的行为不仅是智能的，更是专业和合规的。

工具箱

Agent 的价值最终体现在行动上。工具系统是 Agent 影响物理世界和数字世界的桥梁，其设计的优劣直接决定了 Agent 的能力边界。

同时 tools 也是 Agent 的‘手脚’。我们可以将公司内外部的各种能力无论是调用一个 API、查询数据库、还是执行一个 RPA 脚本都封装成标准化的‘工具’，供 Agent 调用。我们工具箱的丰富性和可靠性，直接决定了我们 Agent 能力的天花板。但这里有几个关键的问题需要关注：

●工具注册与治理：工具如何封装，如何注册，最后如何有效的进行治理？

●执行与编排：当 Agent 决定调用工具时，谁来负责安全、可靠地执行，并处理各种现实世界的异常（如 API 超时、数据格式错误、权限不足）？

●安全与审计：如何进行身份验证、权限检查与意图审计？

认知能力的深化

在我们构建了认知核心、记忆系统和工具系统之后，一个基础的 Agent 已经可以运转。它能够“看到”（感知）、“记住”（记忆）、并“行动”（工具）。然而，要让 Agent 真正能够胜任企业级的复杂、长周期任务，我们必须直面当前主流 Agent 框架（如 ReAct 模式）的固有限制。

ReAct 模式本质上是一种反应式（Reactive）的、一步一思考的决策循环。它在处理定义清晰、步骤明确的短任务时表现出色，但在面对一个模糊、宏大、且充满不确定性的长期目标时，往往会陷入局部最优，甚至迷失方向。例如，对于“将本季度用户流失率降低 5%”这样一个战略性目标，简单的“思考-行动”循环是完全不够的。

因此，为了让 Agent 系统具备处理战略级任务的能力，我们需要在认知核心之上，构建一个更为高级的能力层，专注于前瞻性规划（Proactive Planning）和系统性自我校正（Systematic Self-Correction）。这并非一个独立的引擎，而是对现有认知能力的深化与扩展。

从任务执行到任务分解

一个高级 Agent 必须具备将一个高层、模糊的战略意图，分解为一系列具体的、可管理的、有逻辑依赖关系的子任务的能力。这要求我们的系统：

●具备多层次规划能力：对于“为新产品制定一个为期三个月的上市营销计划”这样的任务，Agent 需要能够生成一个结构化的任务树或有向无环图（DAG）。顶层是战略目标，下面分解为市场分析、内容制作、渠道投放、数据监控等多个阶段性任务，每个阶段任务再进一步分解为具体的执行动作，如“调用 API 查询竞品关键词”、“调用内部 CRM 生成潜在客户列表”等。

●能够进行资源与依赖管理：规划出的任务流，必须考虑现实世界的约束，如预算限制、时间窗口、以及任务之间的前后置依赖关系。这使得 Agent 的规划更接近于一个真正的项目管理专家，而不仅仅是一个指令执行器。目前，如 Tree-of-Thought (ToT) 等研究已经展示了探索多路径规划的可行性，而将其工程化、并与企业实际流程相结合，将是我们重要的研发方向。

从执行失败到归因学习

在复杂的真实世界中，失败是常态。一个仅仅在失败时报错的系统是脆弱的。一个鲁棒的 Agent 系统，需要具备从失败中学习和恢复的能力。这要求我们建立一个系统性的错误归因与校正机制。

1.精细化的错误归因：当一个任务失败时，系统不应简单地返回一个“Failed”状态。我们需要一个“事后复盘”模块，能够自动分析完整的执行日志（包括模型的思考链、工具的调用记录、环境的反馈），并像软件工程中的根本原因分析（RCA）一样，将失败定位到具体环节。例如：

a.规划阶段的逻辑错误？（e.g., 错误地估计了任务的依赖关系）

b.工具执行层面的技术故障？（e.g., 某个 API 超时或返回了非预期的格式）

c.环境理解阶段的认知偏差？（e.g., 错误地解析了网页上的某个信息）

d.还是基础模型的知识局限或幻觉？

2.将经验转化为可复用的知识：在完成归因后，系统应将这次失败的案例——包括问题描述、失败路径、根本原因和（如果可能的话）正确的解决方案——进行结构化处理，并存入长期记忆库。这相当于为我们的 Agent 系统建立了一个可不断增长的“错题本”。未来在遇到类似情景时，Agent 可以检索这些经验，从而主动规避已知的陷阱。

总之，将前瞻性规划与自我校正能力，深度集成到 Agent 系统中，其战略意义在于：它将 Agent 从一个被动的“任务执行者”，升级为一个具备一定自主性、能够处理复杂战略目标、并从经验中持续进化的“问题解决伙伴”。这虽然是当前 AI Agent 领域最具挑战性的前沿方向之一，但它也恰恰是构建长期、可持续技术壁垒的关键所在。

下半场的“北极星”

如果我们认同“下半场”的逻辑，那么结论是显而易见的：评估体系的设计，是未来最重要、最核心、最能构建壁垒的竞争力。

让我们用一个具体的例子来说明。假设我们用一个 AI Agent 来辅助客服。上半场的评估指标可能是“平均处理时长 ”或“首次回复准确率”。为了优化这些指标，Agent 可能会倾向于快速给出标准答案并关闭工单。表面上看，效率提升了。但真实情况可能是，用户的复杂问题并未得到根本解决，导致他不得不再次、甚至多次联系我们，最终的客户满意度和忠诚度反而下降了。这是一个典型的“指标陷阱”：我们优化了一个代理指标，却损害了最终的商业目标。

所以我们的目标应该是构建一个能够衡量真实、长期、商业价值的评估引擎。至于具体怎么做，说实话，我不知道，凭我的设想，它应该包括：

●高保真业务仿真环境：为我们的核心业务流程，构建一个“数字孪生” 。在这个环境中，我们可以模拟数百万次的用户交互、各种罕见的边缘案例、甚至是恶意的攻击行为。这使得我们可以在 Agent 上线前，对其进行低成本、高效率、全方位的压力测试和迭代优化。

●人机回环竞技场：这是一个内部平台，让我们的一线业务专家成为 Agent 的“金牌教练”。他们可以在平台上，对 Agent 在真实（或模拟）任务中的表现进行打分、纠错、甚至提供更优的决策范例。这些高质量的、蕴含着人类专家隐性知识的数据，是我们将 Agent 从“可用”提升到“卓越”的最宝贵燃料。

●长期价值归因分析：与数据分析团队紧密合作，建立严谨的因果推断模型，将 Agent 的引入，与最终的业务北极星指标（如客户 LTV 的提升、运营成本的降低、用户流失率的下降）进行强关联。这使得我们能够用商业语言，清晰地证明 AI 的价值。

●引入“Agent-业务-Fit” (ABF) 的概念：或许我们应该像评估“产品-市场-Fit” (PMF) 一样，为每个 Agent 项目建立一个衡量其与业务契合度的成熟度模型。它包括了从任务成功率、操作可靠性、成本效益，到用户接受度、业务流程融合度等多个维度的综合评分。

最后

AI 的 “下半场” 已经悄然而至，这既带来了巨大的挑战，也蕴含着前所未有的机遇。它挑战的是我们过去的成功经验和思维惯性。然而下半场的 AI，其智能的源泉，也正是我们日复一日工作中积累的、那些无法被量化、但却无比宝贵的领域知识和专业智慧。

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

Sun, 03 Aug 2025 10:09:58 +0000

“

在AI应用的最后一公里，我们面临一个深刻的悖论：我们拥有了前所未有强大的大模型“引擎”，却常常在如何精确“驾驶”它这件事上捉襟见肘。我们真正缺的，或许不是更强的模型，而是更准的“缰绳”。

概览

最近，火山引擎开了一场发布会，端出了两道“硬菜”：一个是性能更强的豆包大模型1.6，另一个则是我们今天要深挖的主角——PromptPilot。

这篇文章会把这两件事给你一次性讲明白。读完本文，你会清晰地了解到：

为何要关注豆包1.6：首先，我们会快速过一遍豆包大模型1.6的升级亮点，并列出它在中文处理、成本、长文本等方面的几个硬核优势，让你明白为何它值得被选入你的生产环境。
主角PromptPilot如何解决痛点：接着，我们会深入本文真正的主角——PromptPilot。带你从头到尾走一遍它的全流程，看它到底是如何通过“生成→调试→评测→优化”的闭环，将写提示词这件“玄学”彻底工程化的。
横向对比：把它放到市场中，与谷歌、微软等大厂的同类产品做对比，看清它的真实水平和独特价值到底在哪。

豆包大模型 1.6

豆包大模型升级了。2025 年 6 月 11 日在火山引擎 FORCE 原动力大会上正式发布豆包大模型 1.6 版本

从原来的 1.5 到现在的 1.6，间隔仅有 140 天（豆包大模型 1.5 版本于 2025 年 1 月 22 日正式发布）。4 个多月出新版本，算得上是很快了。我想团队内部遇到的困难、挑战一定不少，在这些困难下，工程师们交出的结果却一点儿不差，令人尊重。

现在你可以通过 https://www.volcengine.com/experience/ark?model=doubao-seed-1-6-flash-250715 来体验 1.6 版本的模型，会送 50 万 token。

大概介绍一下 1.6 模型，主要有以下两个子模型：

Doubao-Seed-1.6-thinking｜250715：模型思考能力大幅强化，对比 Doubao-1.5-thinking-pro，在 Coding、Math、逻辑推理等基础能力上进一步提升，支持视觉理解。支持 256k 上下文窗口，输出长度支持最大 16k tokens。
Doubao-Seed-1.6-flash｜250715：推理速度极致的多模态深度思考模型，TPOT 仅需 10ms；同时支持文本和视觉理解，文本理解能力超过上一代 lite，纯文本能力大幅提升近 10%。支持 256k 上下文窗口，输出长度支持最大 16k tokens。

从我个人的使用体验上看，1.6 比 1.5 强了很多。据悉，在众多权威评测集上，豆包大模型 1.6 的得分均位居国际第一梯队。

可能很多人有这样一个问题：有那么多模型，我为什么要选择豆包？

嗯，确实，市面上众多模型，开源的也好，闭源的也罢，除了国民级别的豆包 APP，好像豆包大模型的存在感不太高。然而实际上可能只是你不知道，我来列举一些，你可能真的想在生产应用中使用豆包大模型的原因：

中文准确度必须顶尖（教育、政务、法律），比如在 2025 年高考数学新高考卷实测拿到 144/150，中文复杂推理居国内榜首
国内首个 256 K token 对话模型，单条上下文 > 128 K（长合同、源代码库、历史聊天）
成本：0–32 K 输入只要 ¥0.8/百万 token，综合成本是上一代模型的 1/3
能够“看图说话”或读视频（电商质检、巡检、短视频客服）：60 项公开多模态基准 38 项第一
通过中国网信办算法备案：豆包已完成“网信算备 110108823483901230031”备案，可直接商用

心动吗？如果你要做一个 AI 应用，我想以上每一项都对你的模型选型很重要。

PromptPilot

随着豆包大模型 1.6 更新的，还有今天的主角 PromptPilot

众所周知，Prompt（提示词）作为大模型的核心输入指令，直接影响模型的理解准确性和输出质量。优质的 Prompt 能显著提升大语言模型处理复杂任务的能力，如逻辑推理、步骤分解等。

作为 AI 应用的资深玩家，写提示词几乎成了每天必须要做的事情，我不但使用 AI 工具，还开发 AI 产品。就拿最近做的一个 RAG 项目来说，在整个 RAG pipeline 中，有一个很重要的环节就是 “响应生成”。顾名思义，就是通过 prompt 驱动 LLM 生成结果。其实 prompt engineering（提示词工程）在整个 AI 应用中的性价比是极高的，要知道对整个技术工程进行优化的成本其实是相当大的，而且往往有时候投入产出不成正比，但 prompt engineering 不一样，一个好的提示词返回的结果质量可能比一个差的提示词强 10 倍，这在我们研发团队内部是有共识的。

prompt engineering 看起来是叫“提示词工程”，但在实践中，它缺少传统工程的严谨范式，它不像其他可工程化的技术那样有明确的流程和标准，甚至与传统‘技术’的关联也显得不那么紧密。写提示词不用懂技术，不用会编程，语文和表达力好就够用了。

然而这正是这个问题的症结所在，没法工程化，写提示词不成了管理的玄学了吗？系统、应用可不能由着你的性子玩儿“抽卡”啊，技术上一定要落地，一定要明确才行。但整个 AI 生态上，大家都在忙于开发模型，忙于开发基于模型的应用，或者大家觉得写提示词太简单？总之并没有很好地把写提示词这个问题工程化地解决好，对于 prompt engineering ，从我的经验看，至少有以下几个痛点：

太容易上手但又不容易写好
写出来效果不满意不知道怎么优化
没有客观的评价标准，很难说什么是好的提示词
经常变更，写了新版忘了旧版，版本和生命周期全靠手动维护

随着我们项目开发的深入，以上这些问题我们也使用了一些办法，比如：

利用提示词模板固定提示词，将变量提出，前期手动管理提示词和提示词模板的版本与生命周期，后期开发系统功能来管理。
与客户一起编写 Q/A 手册，一来为了将问题和标准回答定义清晰，二来为了验收做准备。研发团队基于 Q/A 可以有的放矢地对整个工程以及提示词进行优化。
虽然客户不一定懂 prompt engineering，但知道什么是满意的结果什么是不满意的结果，通过点头 Yes 摇头 No 的方式来逐步固定提示词的衡量标准

其实从项目和工程的角度，诸如以上的办法我们还有一些，但作为一个开发者，这些办法一点儿“技术的味道” 都没有，它很别扭，不是说我们要为了技术而技术，而是技术是确定性的，可落地的，有保障的东西，没有工程来管理这个事儿，总让我不踏实。整个 prompt engineering 的过程可以说一点儿都不丝滑。里面有很多人工、手动、流程和制度的东西，太原始了，啥呀这是，什么时代了，一定有更好的解决办法才对。所以我一直在找，幸运的是我没找太久就看到了 PromptPilot ，只一眼，我就知道，就是它了，它能解决我的问题！

PromptPilot 简介

“

火山引擎出品的 PromptPilot 提供全流程智能优化，涵盖生成、调优、评估和管理全阶段。

我引入了官方文档的一句话，我想这句话就够了，一句话就解决了我之前所说的几乎所有痛点。

目前可以通过两个入口使用（限时免费 90 天 2025.06.11-2025.09.11）：

独立站：https://promptpilot.volcengine.com/home
火山方舟：https://console.volcengine.com/ark/region:ark+cn-beijing/autope/startup?

下面我分别说一下它是怎么解决我的痛点的。

从生成一个 prompt 开始

我经常看到一些刚接触 AI 大模型的伙伴，在起初面对大模型时手足无措，不知道应该怎么写 prompt ，实际上我开始也不太清楚要怎么写，但好在我经常写文章，还有一些经验，至少我能把事儿说明白，大模型给我的反馈也还不错，我把我的这种方法称为 “白描”。然而并不是所有的事情都可以通过“白描” 来解决，有时候你用对了一个专业词汇就能够提升 90% 的效果，而正常情况下我们不太可能对所有领域的专业知识都精通，所以用不对词汇，写不好提示词几乎成了常态。

于是我们好像很崇拜那些把提示词写的很好的人，纷纷效仿、分享、学习提示词，比如李继刚，他写的提示词用到了编程语言 Lisp 的一些特点。Lisp? 别说外行了，就是专业的程序员也很少有会的了。

那我们怎么办呢？就像你明明来到了装有宝藏的房间大门前，却说不出打开门的咒语，一个劲儿地在那儿：“阿巴阿巴” ，像个傻子一样。

promptpilot 给了我答案，那就是：“用魔法打败魔法，最终实现 prompt 袪魅”

这里我输入了一行自己写的 prompt： “判断舆论的内容对出行行业的影响”，点击 “生成 prompt” 就会在右边自己生成一个结构化的 prompt:

 1你的任务是判断给定舆论内容对出行行业的影响。请仔细阅读以下舆论内容，并根据出行行业的特点进行评估。
 2舆论内容：
 3<public_opinion>
 4{{PUBLIC_OPINION}}
 5</public_opinion>
 6在评估舆论对出行行业的影响时，请按照以下步骤进行分析：
 71. 仔细阅读整个舆论内容，明确其核心观点和主要信息。
 82. 思考出行行业的各个方面，如交通方式、市场需求、企业运营、政策法规等。
 93. 分析舆论内容可能对出行行业的这些方面产生的直接或间接影响。
104. 考虑舆论的传播范围、影响力和受众反应，以及这些因素如何放大或缩小对出行行业的影响。
115. 形成初步判断，并再次检查，确保没有遗漏重要细节。
12
13在<思考>标签中详细分析舆论对出行行业的影响，考虑其可能涉及的各个方面。然后在<判断>标签中给出明确的影响判断结果，如“积极影响”“消极影响”“无明显影响”等。最后，在<解释>标签中详细解释你的判断理由。
14<思考>
15[在此详细分析舆论对出行行业的影响]
16</思考>
17<判断>
18[在此给出明确的影响判断结果]
19</判断>
20<解释>
21[在此详细解释判断的理由]
22</解释>
23请确保你的判断客观公正，并基于对舆论内容和出行行业的综合分析。如果舆论内容对出行行业的影响模棱两可，请在解释中说明你的考虑过程。

promptpilot 不但生成了结构化的 prompt，还自动提取出了变量 {{PUBLIC_OPINION}}。此外在现有结构化 prompt 的基础上还可以点击功能按钮持续优化。

这个功能总结来说就是：“简单描述你的需求，一键生成结构化的 prompt，输入你的修改意见，即刻智能改写。也可以框选局部文字，精准调整每个细节，帮你初步获得一个不错的 prompt”

不知道是不是我的错觉，因为最近一直在 vibe coding，所以用着用着 promptpilot 总感觉他们产品的很多功能可能就是 AI 写的，哈哈。

我们稍微想一想这个功能的实现原理。我给他一段自己写的 prompt，他给我一段丰富的结构化的 prompt，还能继续优化，这一看就是用提示词让 AI 对我的提示词进行了重写啊。这不就是 “用魔法打败魔法” 吗？所以对 prompt 袪魅吧朋友们，也没啥难的，但我一直对 AI 是有警觉的，我的意思是工具你可以用，好的工具更可以用，你完全可以放心大胆的使用 promptpilot，但请你看一看这个名字里有个 pilot，领航员。看过拉力赛车吧，坐主驾旁边念路书的那哥们，很重要，但是没他人家主驾也能开车。《飞驰人生 2》中张驰在最终的比赛时，能不靠路书心不慌、面对使坏的对手大胆碰撞超车，赢得比赛的胜利,靠的是自己的经验和能力。

promptpilot 或任何 AI 工具给你的东西，至少你要看一下，最好跟着他学习成长起来，如果渐渐地把自己的主动思考“让渡” 出去，最终你可能会成为个 “废物” ，最简单的提示词你都不会写了，这不是什么危言耸听，看看《机器人总动员》中，远在宇宙飞船中的人类因为过度依赖机器人自己什么都不干变得又胖又无能的样子，那可能就是你的未来。

调试 prompt

写好了 prompt 以后，我们还需要调试，点击“验证 prompt" , 进入调试界面：

进入到调试页面后，我们可以设置变量、继续改写与优化 prompt、选择不同的大语言模型，并生成模型回答，总之就是不断调试并查看 prompt 的最终生成效果如何。

在你不断优化 prompt 的过程中无需关心版本的问题，系统会自动记录并管理提示词版本，你可以放心回退：

评测

在完成调试后，接下来就该进行评测了。

评测的目的是：在不同数据情况下验证 prompt 的效果如何，用各种 case 来检验 prompt 写的有没有问题，进而有针对性的进行优化。

了解了目的，我想下一步你一定猜到了，那就是准备评测数据。

哎呀，准备数据，这就有点儿烦人了，但没关系，promptpilot 帮你做了一个“AI 生成变量” 功能，之前生成的 prompt 不是已经自动帮我们提取出了变量了吗？在此基础上，它还可以再帮我们生成变量的数据，这评测数据不就有了吗？

如上图所示，一键生成了三行数据，三个变量自动生成，我们只需要根据自己的实际情况稍微调整一下内容，再点击一下蓝色按钮就可以批量生成模型回答了。

当然你也可以自己做评测数据，根据要求上传个带变量名字段的文件就可以：

你还可以对模型回答的结果进行评分，就是看回答的内容是否是按照你的提示词要求给的，质量如何。

评分甚至可以让 AI 自动评，评分规则也可以自己写或让 AI 帮你写。

可能你注意到了有一列是 “理想回答”，我个人认为这一列非常重要，所谓定标准，就是要告诉人家什么是好的，一个问题问出去，如果你自己都不知道什么是好的答案，那 AI 其实也无能为力，它还没有那么聪明。这一点可能对于大部分 C 端用户不太好接受，因为就像你没有使用苹果手机前你是不知道你想要一个 iPhone 的，长期以来你被创造出来的需求所满足，习惯了，你觉得别人告诉你喜欢什么很正常，你自己不知道也很正常。

对，是很正常，那是因为场景不同。在面对不同客户，不同需求，不同场景下，我们的解决方案也不同。对于 C 端场景可能真的就是那样，商家可以创造需求，创造价值。但对于 B 端客户是需要解决问题、满足需求，不要乱创造你以为的价值。

在 B 端场景下，需求必须是明确的，解决的问题是清晰的，问题的答案是满意还是不满意也一定得是确定的。这是项目落地的必要条件！

就像考试的试题有标准答案一样，当有了标准答案，自然就有清晰的方向和路径来解题了。所以 “理想回答” 这一列的重要性不言而喻。无论对于评分还是后续的智能优化都有极大的帮助，原因很简单，目标有了，剩下的就是如何达到目标的事儿了。

智能优化

当你完成了评测，就可以点击右上角的 “智能优化”

大模型将对 Prompt 进行优化（模型回答和评分齐全的数据会用于智能优化），优化完成后你将获得：1.AI 智能优化后的 Prompt；2. 使用新 Prompt 生成的回答与评分

优化完成后，还将输出一份内容详实的优化报告

这一步其实还是对我最初的 prompt 进行优化，只不过因为有了更多的评测数据以及评分作为依据，优化方向更为明确，那么优化结果也一定更切合实际。

视觉理解

因为 prompt 是文本，promptpilot 最终生成、优化的也一定是 prompt 文本。也就是说输出是定死了的，就是“文本”，但输入可是多样的，除了文本的理解，promptpilot 还支持视觉理解。别误会，目前只支持图片。

我们来举一个具体的例子，我来一步一步操作一下整个流程。

首先我们创建提示词，我的初始提示词是：

1“为了安全生产，你需要根据生产车间的图片，判断生产车间是否存在违规操作设备和未佩戴安全帽的情况，需要给出违规类别。”

我看了下右边生成的 prompt 觉得变量名太长，于是我想改一下，把变量名改成 image_url，就直接鼠标选中变量名进行改写

改写生成后的 prompt 是这样：

 1你是一位专业的图像分析专家，专注于安全生产领域。你的任务是根据提供的生产车间图片，判断车间是否存在违规操作设备和未佩戴安全帽的情况，并给出违规类别。
 2
 3## 输入：
 4- 生产车间图片：{{image_url}}
 5
 6## 判定标准与违规类别定义：
 71. **`是否存在违规操作设备`**: （字符串，"是"/"否")
 8 - **判定**: 图像中是否存在工人违规操作设备的情况？
 9 - "是": 至少有一人正在违规操作设备。
10 - "否": 无人违规操作设备，或者图像中无人操作设备。
11 - **违规类别**: 若判定为“是”，违规类别标记为“违规操作设备”。
12
132. **`是否存在未佩戴安全帽`**: （字符串，"是"/"否")
14 - **判定**: 图像中是否存在工人未佩戴安全帽的情况？
15 - "是": 至少有一人未佩戴安全帽。
16 - "否": 所有人都佩戴了安全帽，或者图像中无人。
17 - **违规类别**: 若判定为“是”，违规类别标记为“未佩戴安全帽”。
18
19## 输出格式：
20请按照以下 JSON 格式输出你的判断结果。所有字段的值必须是字符串 “是” 或 “否”，违规类别若存在多个以逗号分隔，若不存在违规则标记为“无”。
21{
22 "是否存在违规操作设备": "是",
23 "是否存在未佩戴安全帽": "否",
24 "违规类别": "违规操作设备"
25}

接着我们开始调试这个视觉理解的 prompt：新建一个内容理解任务，点击加号

复制之前改写好的完整 prompt 到调试 prompt 栏里面

上传一个图片数据，这里采用 url 上传，并点击确定

1https://img0.baidu.com/it/u=1094762033,1331895175&fm=253&fmt=auto&app=138&f=JPEG?w=500&h=561

选择 target model，即：推理模型，多模态选择带 thinking 的模型

保存并生成模型回答

获取理想回答：平台对同一个 case，提供了不同模型回答的结果给用户参考，用户可以自由选定好的答案，并基于选定的答案进行反馈拿到理想回答。这里作为示例，取模型回答 2 的结果，并点击应用。

感觉他的思考过程太重复啰嗦了。因此做如下反馈：

1思考过程简洁一点

然后就可以保存并添加到评测集了。后面就是添加评测数据，你可以一行一行编辑，也可以直接上传个文件，比如

最终的效果类似这样：

然后就可以按照前文一步一步地进行 prompt 调优、打分、智能优化并生成优化报告了。

你看，总之，图片它也是能够理解的，甚至还有更复杂的任务也可以（不过还处于 beta 状态），比如在一个复杂场景下检查人数：

promptpilot 使用流程

前文写的内容有点儿多，这里我们总结一下 promptpilot 的使用流程，我们从官方文档中找个图来说明一下

初看可能有点儿复杂，但只要你真正用几回 promptpilot 再看这个图就会感觉无比的清晰了。

我们通过视频再快速回顾一下 promptpilot 的核心功能

已关注

Replay Share Like

观看更多

退出全屏

切换到竖屏全屏**退出全屏

小盒子的技术分享已关注

Share Video

，时长01:35

0/0

00:00/01:35

切换到横屏模式

继续播放

进度条，百分之0

Play

00:00

01:35

倍速

全屏

倍速播放中

0.5倍 0.75倍 1.0倍 1.5倍 2.0倍

超清流畅

Your browser does not support video tags

继续观看

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

观看更多

转载

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

小盒子的技术分享已关注

Share点赞Wow

Added to Top StoriesEnter comment

Video Details

提示词工程产品对比

横向对比

其实还有其他的主流的提示词工程解决方案，比如：

Azure Prompt Flow（微软）
Vertex AI Studio（谷歌）
Amazon Bedrock Prompt Playground（亚马逊）

篇幅限制，我就不一一介绍了，这里简单介绍一下 Vertex AI Studio，通过对比，你会对 PromptPilot 的水平有更深刻地了解。

Google 家的 Vertex AI studio 提供了一个直观界面，让你能够以低代码或甚至无代码的环境来构建 GenAI 应用，你能通过 Prompt, 连接后台，最后反馈结果。

关于提示词工程部分，它的核心功能有：零次提示（Zero-shot prompting）、单次提示（One-shot prompting）和少量提示（Few-shot prompting）。

零次提示：是指在不提供任何例子的情况下，直接向模型发出请求，使其适应特定的行为。
单次提示：是指向模型提供单个任务示例，以此来引导模型的输出。
少量提示：则是提供少量的任务示例。

然后就没有然后了，对，就这些，界面很 google 很简单。

我看了一下 Azure Prompt Flow 和 Amazon Bedrock Prompt Playground 感觉产品逻辑和 Vertex AI studio 差不多。

你可能已经发现，与 PromptPilot 相比，谷歌、微软、亚马逊这三大云服务商在提示词工程上的产品功能显得相对单薄。这主要是因为它们的产品方向和侧重点有所不同：三大云把 Prompt 工程塞进整条 LLM DevOps 流水线，它们把 Prompt 当作 LLM 应用流水线里的一环，仅提供“写＋测”或“写＋存＋跑”，深度要靠开发者自己拼接脚本或流水线。而 PromptPilot 把“提示词”当作核心产品做了纵深。把 “提示词” 的写 → 调 → 测 → 版本管理等全部动作做了深耕。

因此，当你的主要痛点就是“写好提示词”而非“布好全链路”，PromptPilot 会显得顺手；而当项目需要管部署、监控、成本、接第三方工具时，Prompt Flow 等全栈 IDE 的价值就会凸显出来。

而类似三大云厂商做的那种 LLM 流水线产品可以在火山引擎上找到，在 AI 时代，阿里云、腾讯云、火山引擎是我比较喜欢的国内云厂商三巨头。之前也用过华为云，它的市场占有率也很高，但可能客户群体和技术方向的问题，在 AI 时代，它的声音并不多。

纵向对比

从深耕提示词工程的角度来说，PromptPilot 身上也有不少优秀产品的影子，比如：promptlayer、Prompt Optimizer 。

有这么多优秀的产品，足以见得提示词工程的需求在一段时间内还是存在的，需要被满足。但对比多家产品，我觉得 PromptPilot 目前做的是最好的，没有之一。

最后

PromptPilot 的最大价值在于通过自动“写+测+改” 把写 Prompt 这件“小事” 完全工程化产品化，让使用者几乎零门槛的使用，无论对于开发者还是小白都非常友好，我猜测将来甚至可以直接集成到企业级 AI 开发流水线中。

另外不得不提一下的是，豆包大模型是商业模型，那么火山引擎作为一个云平台一定会引导用户用自家的大模型，所以构建“护城河” 这个事儿是一个常规操作，很正常。目前除了自家的豆包大模型，promptpilot 也支持 DeepSeek 等其他模型。

我相信未来在模型使用上，火山的策略不会那么激进，而会采用融合、共赢，权重优先的方式，长期允许多模型共存，但一定会在自家模型的推广和销售上大做文章。

最后，我想说，在 AI 领域，未来一定会有越来越多的新产品出现，而所有这些产品都像是一个时代的注脚，你需要明白的是，时代不同了，AI应用开发正在从“炼丹师”式的个人英雄主义，走向体系化的工业生产阶段。在这个过程要解决的问题和相应的机会会很多，但只有真正务实地的解决问题的团队才能够赢得未来，因为他们行动深刻表达了四个字：“价值创造”。

让 AI 模型瘦身提速：揭秘量化技术

Sat, 07 Jun 2025 14:30:00 +0000

想象一下，如果我们能把动辄几百MB的大型AI模型“压缩”到手机里运行，是不是很神奇？这并非天方夜谭，其中的关键就是量化技术。近年来，量化已成为人工智能领域的热门话题，通过给模型做“减法”，让AI模型变得又轻又快。

什么是量化？

通俗地说，量化就是降低数字表示的精度，把原本高精度的数值变为低精度。例如，本来AI模型的参数用32位的浮点数（FP32）表示，现在改用8位的整数（INT8）来表示。也就是说，用更少的比特位去表示同样的信息。这样做相当于给模型进行了压缩：所需存储空间大大减少，计算起来也更简单。需要注意的是，精度降低往往会带来量化误差，也就是模型预测的细微准确率损失。一般情况下，我们以8位量化为目标（即INT8），目前业界也已成功尝试更低的4位量化。量化过程本质上就是用压缩技术将更多比特的数据转换为更少比特的数据，同时尽可能保持模型性能不大打折扣。

为什么量化很重要？

随着AI模型（尤其是大模型）的规模爆炸式增长，模型的计算负担和部署难度也水涨船高。量化正是一剂“瘦身良方”，在尽量保持模型准确性的前提下，大幅降低模型的资源需求。这对现实应用而言意义重大：

⚡ 更快的推理速度：量化把模型的计算从浮点运算变为整数运算，单次计算所需处理的位数减少，矩阵乘法等操作自然更快。这能显著降低模型响应延迟，在保持精度基本不变的同时大幅提升推理速度。对于需要实时响应的应用来说（如语音助手、实时翻译），速度提升至关重要。
📱 本地运行与高效部署：当我们希望在移动设备、边缘设备上运行AI模型时，量化几乎是不可或缺的工具。将浮点表示转换为低精度整数后，模型的计算与内存需求大幅下降。这意味着笔记本、平板、智能手机甚至微控制器上都可以跑得动原本“跑不动”的模型。举例来说，采用TensorFlow Lite对模型进行INT8量化，可以让模型体积缩小约75%，推理速度提高4倍左右，而准确率仅轻微下降约2%。如此一来，我们的手机也能流畅运行起复杂的AI功能。
🔋 降低功耗：模型计算量减小直接带来能耗降低。对于电池供电的设备（手机、笔记本、物联网传感器等），量化后的模型更省电，延长设备续航。在自动驾驶汽车中，车辆需要依靠电池或有限的供电运行大量AI算法。通过INT8量化，这些车辆可以更快地做出实时决策，同时消耗更少能量，让电动车续航更久。
💾 模型更小巧：经过量化压缩，模型体积和内存占用都会大幅缩减。模型文件更小，意味着传输、存储都更方便，也降低了对硬件内存的要求。很多大型网络（如原始的VGG-16有超过500MB）无法直接部署在小设备上，但经过8位量化，内存和带宽占用最多可减少四分之三，让原本笨重的模型变得轻盈。
🤝 兼容性与可移植性：量化后的模型使用整数运算，这使其可以在一些不支持浮点运算的旧平台上运行。同时，由于模型更小、更“平易近人”，普通的消费级GPU甚至CPU都能跑得动，这大大拓宽了AI模型的可部署范围。例如，一些老式嵌入式设备、本地浏览器环境等，都可能因为量化技术而得以跑起机器学习模型。

综上所述，量化让AI模型在速度、效率、能耗和适用性方面都得到提升，堪称AI模型优化的利器。正因为这些优势，量化已经成为从云端服务器到边缘设备各类AI部署中的关键工具。

量化是如何实现的？

量化听起来很美好，那么具体是怎么做到的呢？核心思想其实不难：确定一个映射规则，把原来范围很大的浮点数映射为范围较小的整数。通常做法是计算一个缩放因子，用它把32位浮点值缩放并四舍五入到最接近的8位整数值。例如，某模型权重向量的最大值是6.2，那么以INT8范围[-127,127]来说，我们用127/6.2≈20.5作为缩放系数，把每个浮点数乘以20.5再取整，就得到对应的整数值。通过这样的线性映射，原始的权重就转换到低精度表示了。当然，这样难免引入一定误差，需要结合算法尽量减少误差影响。

在具体实现上，常用的量化流程主要有两种：

训练后量化 (PTQ)：顾名思义，就是在模型训练完毕后再对模型进行量化处理。直接将已有模型的权重从浮点表示转换为定点的低精度整数表示即可。这种方法不需要重新训练模型，因而速度快、所需数据少，非常实用。当你已经有一个效果不错的模型，想让它运行更快、更省资源时，PTQ是很好的选择。然而，PTQ相当于事后压缩模型，难免出现一些性能下降，即模型精度可能有所降低。
量化感知训练 (QAT)：这是把量化融入训练过程的一种方法。在模型预训练或微调阶段，就模拟低精度运算来调整权重。简而言之，就是让模型在训练时就“意识到”日后要用低精度计算，从而提前学会适应。这样训练出来的模型对量化的精度损失更不敏感，因而最终精度往往比PTQ方式更高。但QAT的代价是需要更多的计算资源和大量代表性数据来训练——等于重新训练或微调一遍模型，所以成本更高。因此，通常在有充足的数据和算力预算、且追求极致模型性能的情况下才会选用QAT。反之，如果预算有限或者模型已经足够好，那PTQ就更实惠。

除了以上两种主要方式，还有量化过程中的一些技术细节，比如动态量化和静态量化。简单来说，两者差别在于如何确定量化时的取值范围（也称校准）。动态量化是在模型运行时根据每批输入动态计算最佳范围，使模型获得更高精度；静态量化则在部署前用一批数据先离线计算出固定范围，应用于所有后续推理。动态方法往往精度好但实现复杂，而静态方法较常用但需要仔细选择校准数据。无论采用哪种策略，目标都是找到平衡精度和效率的最佳量化方案。

值得一提的是，现在主流的深度学习框架（如TensorFlow、PyTorch）都提供了完善的量化工具包，帮助开发者一键将模型量化，无需事必躬亲计算缩放系数。例如，TensorFlow Lite支持直接将Keras模型转换为INT8量化的.tflite模型，用于移动端或微控制器部署。这些工具让量化实施变得简单高效，降低了技术门槛。

量化的挑战

量化有诸多优点，但也并非万能药，在应用中需要权衡以下挑战：

🎯 精度下降（准确率损失）：正如前面提到的，量化引入的误差可能导致模型预测精度下降。对于一些对细节敏感的任务（如医疗影像分析、自然语言处理）来说，哪怕1-2%的精度变化都很重要。一般来说，模型参数越多、结构越复杂，量化带来的累计误差可能越明显。特别是超大型的LLM模型，层数深参数多，如果直接量化，误差会层层叠加，造成显著性能下降。因此在应用量化时，需要通过校准、QAT等方式尽量降低精度损失，把量化误差控制在可接受范围。
💰 实现成本与复杂度：采用更高级的量化方案（例如QAT）往往意味着更高的计算和时间成本。对一些资源有限的团队来说，从头训练一个量化感知模型并不现实。所以很多情况下会选择折中的PTQ，即使牺牲一点性能也无妨。这就涉及一个取舍：精度 vs 成本。此外，不同硬件对低精度计算的支持程度不一，实现量化需要考虑软硬件配合。如果部署平台缺乏对INT8等低精度运算的优化，反而可能达不到预期的加速效果。开发者需要针对具体硬件进行测试调优。有时还需结合其他压缩手段（剪枝、蒸馏等）一起使用，才能达到理想的模型大小和速度。这些都增加了实现量化的复杂度。

总的来说，量化的挑战在于平衡：一方面是尽可能降低模型尺寸和计算量，另一方面是尽量保持模型原有的准确率不受大的影响。这种平衡需要根据具体应用场景反复试验和拿捏。不过，随着算法和芯片的发展，量化带来的精度损失正在逐步减少，新技术甚至探索4位、2位量化还能维持不错的效果。这使得量化正越来越成熟可靠，成为AI模型优化的常规选项。

实际应用场景

量化技术已经广泛应用于各种AI场景中，让原本笨重的模型走入寻常百姓家。以下是几个贴近生活的例子：

📱 智能手机上的AI：我们的手机中藏着许多AI功能——相册应用的图像识别、语音助手的语音识别、摄像头的实时滤镜等等。这些功能背后的模型都受益于量化技术。通过8位量化，模型变小变快，手机才能离线实时完成复杂计算，而不会让电池瞬间耗尽。比如，Google Lens等应用据报道就使用了INT8量化模型，在手机端流畅运行，同时不至于发热严重或很快耗电。可以说，没有量化，就没有如今手机上丰富的AI体验。
🚗 自动驾驶与车载AI：自动驾驶汽车需要依赖大量神经网络模型来处理摄像头、激光雷达等传感器数据，从中识别行人、车辆、交通标志并做出驾驶决策。这些模型必须在车载计算平台上实时运行，容不得半点延迟。通过量化，车载AI模型的推理速度大大提高，每毫秒都得到珍惜。更快的模型意味着汽车可以更及时地刹车或转向，保障行车安全。同时，量化模型计算量低，也减轻了车辆电力系统的负担。毕竟，电动汽车上一块GPU很耗电，而模型瘦身后就能在有限算力下完成任务，让自动驾驶系统运行更长时间、更稳定。
🌐 边缘设备与物联网：在农业、工业、安防等领域，越来越多的小型边缘设备也开始搭载AI。例如，农田里的物联网传感器可能运行着一个微型的作物病虫害预测模型。这种传感器往往只靠电池供电，需要连续工作数月不更换电池。通过将模型量化为INT8，这些传感器上的“小模型”既可以快速处理数据，又将功耗控制在极低水平。有报道显示，农场里的IoT设备利用量化后的模型来预测灌溉需求或病虫害风险，量化确保模型以极低能耗实时运行，让传感器在不充电的情况下运作数月之久。同理，在安防摄像头上部署的人脸识别、在可穿戴设备上的健康监测算法等，都因为量化得以在计算资源有限的设备上实现。这为AI的普及打开了广阔的应用空间。

以上种种场景表明，量化技术正悄然推动着AI从云端走向本地，从大型服务器走向我们身边的各类小设备。无论是手机、汽车还是物联网传感器，量化让AI模型接地气地融入各种行业和日常生活。

最后

在AI模型优化的众多手段中，量化可谓简单却威力巨大的一招。通过让模型“瘦身”，我们能以很小的代价换来可观的性能提升和部署便利。当然，量化并非没有代价，如何在效率和准确率之间取得最佳平衡是一门艺术。但随着技术演进，这个平衡点正变得越来越高效。可以预见，未来更低比特的量化方案（如4位甚至更低）可能走向实用，为AI模型带来更极致的压缩与加速效果。

Rag chunk 之：Excel 文档解析

Fri, 06 Jun 2025 01:39:11 +0000

前言

处理 Excel 文件时会遇到一些独特的挑战。与典型的结构化格式不同，由于合并单元格、多个表头、嵌入式图表和非传统的布局（这些布局主要设计用于人阅读而非机器解析）等元素，这些文件在数据提取和处理方面存在障碍。

在处理 Excel 时可能会遇到各种 Excel 文件格式，从现代的 .xlsx 到旧版的.xls 或宏启用版的 .xlsm 文件，每种格式都需要不同的解析方法和库。跨工作表或单个工作表内的数据不一致进一步使过程复杂化。非标准文件通常缺乏统一性，呈现不同的列顺序、不一致的日期格式或列内混合的数据类型，需要强大的错误处理和数据验证机制。

合并单元格对解析算法来说尤其成问题，因为它们可以跨越多行或多列，使数据关联变得复杂。必须编写程序逻辑来准确处理这些合并区域。隐藏的行、列或工作表增加了另一层复杂性，需要彻底检查整个工作簿以确保完整的数据提取。

为应对这些挑战，必须开发稳健、灵活的解析解决方案。这通常涉及结合多种方法，例如使用专门的 Excel 解析库、为特定文件结构实现自定义逻辑，以及采用机器学习技术对半结构化数据进行模式识别。

预处理

在分块前处理合并单元格、复杂公式和非表格数据。这些属于预处理。

合并单元格问题

在对 Excel 进行分块之前，必须先把「合并单元格导致的信息缺失」消除，否则嵌入时会出现 NaN 或空字符串，严重影响检索召回。

为什么要先处理合并单元格？

我们以一个 “功能清单.xlsx” 为例：

读取时只保留左上角值：无论 openpyxl 还是 pandas.read_excel，合并区域内除左上角外其余格值会被置空。
行级分块会丢字段：合并了“模块名称”或“子系统”的行，在转换成文本时会缺列，导致检索无法定位。
RAG 检索依赖元数据：若模块名丢失，metadata_filter 将失效，回答准确率显著下降（内部测试下降 15–25 pp）。

解决方案

思路：

利用 ws.merged_cells.ranges 拿到所有合并区域
读取左上角值，遍历填充到区域内每个单元格。
调用 ws.unmerge_cells() 取消合并，再保存临时文件供 pandas / Unstructured 后续处理。

 1from openpyxl import load_workbook
 2
 3def explode_merged_cells(path_in: str, path_out: str):
 4 wb = load_workbook(path_in)
 5 for ws in wb.worksheets:
 6 for rng in list(ws.merged_cells.ranges): # 复制，以免迭代中修改
 7 ws.unmerge_cells(str(rng)) # 先解除，否则无法写值
 8 tl_cell = ws[rng.min_row][rng.min_col - 1] # 左上角 Cell
 9 for r in range(rng.min_row, rng.max_row + 1):
10 for c in range(rng.min_col, rng.max_col + 1):
11 ws.cell(r, c).value = tl_cell.value
12 wb.save(path_out)

核心 API 参考：unmerge_cells() 、merged_cells

Chunking 策略

我手头有一些《功能清单》和《工时评估表》就以这些文件为例，讨论一下具体的 chunking 策略，具体来说，是使用 两级分块

什么是“两级分块”？

两级分块本质固定：父 = 模块/功能域，子 = 行记录。

Azure 官方指南将这种把大块再拆子块的做法称作“层次化 chunking/hierarchical chunking”，可与 Auto-Merging Retrieval 等检索算法天然配合

功能清单与工时评估表本质是一条条功能点记录；行级粒度最能保持“一问就能命中一行”的高精检索。
单纯行级又易丢失上下文，例如“所属子系统”；用业务模块字段先聚合可在召回时带来更丰富的背景。
如果某模块非常大，使用递归切分（递归字符或 token 限长）可以在不破坏结构的情况下继续拆分。

具体来说是：模块 → 行先聚后拆，更适合 Excel 表中已有明确模块列、需要用向量库分区或 metadata 过滤的系统

处理流程上务必：

先处理合并单元格
行文本带列名
metadata 保留 module 字段，以便精准过滤与 Auto-Merging 聚合。而元数据的处理（模块、行号、sheet 名），决定了查询过滤与答案上下文的可控性。

详细说明

两级分块中的父和子，具体来说是：“摘要型父块 + 行级子块”

父块

父块的存在价值在于提供业务背景 + 索引锚点。比如 “模块 A：支付结算；记录 426 行” 。
父块采用“header + 小块”策略

为什么父块可只包含结构信息？

父块不包含子行信息，因为子块检索命中后，通过父 ID 回溯获得模块级上下文，提高回答完整度。
在层次化 (hierarchical) 分块体系里，“父块 (parent document)” 的核心职责是让检索器知道一批子块属于哪个业务语境，而不是存放子块的全文内容。
通常父块只保存模块级背景（例如模块名、描述、记录数等），不再内嵌每一行子块的具体文本；这样既保上下文，又避免重复嵌入

代码：父块仅含结构信息的实现

 1
 2import pandas as pd
 3from langchain.docstore.document import Document
 4from langchain.text_splitter import RecursiveCharacterTextSplitter
 5
 6df = pd.read_excel("functions_flat.xlsx", engine="openpyxl")
 7
 8# ➊ 生成父块——只保背景
 9parent_docs = [
10 Document(page_content=f"模块名称: {m}\n总记录数: {len(sub)}",
11 metadata={"module": m, "level": "parent"})
12 for m, sub in df.groupby("模块")
13]
14
15# ➋ 生成子块——行文本
16row_docs = []
17for _, row in df.iterrows():
18 md = "\n".join(f"**{c}**: {v}"for c, v in row.items())
19 row_docs.append(Document(page_content=md,
20 metadata={"module": row['模块'], "level": "child"}))
21
22# ➌ 可选：对子块再递归切分，确保 <2048 chars
23splitter = RecursiveCharacterTextSplitter(chunk_size=2048, chunk_overlap=256)
24child_chunks = splitter.split_documents(row_docs)

ParentDocumentRetriever 在检索时会先命中 child_chunks，随后自动用父 ID 把对应模块摘要拼回上下文。如需“关键列拼接”模式，只需把 row[[‘ID’,‘Name’]] 等字段 join 到父块内容。

子块

在“模块 → 行”层次化分块里，子块（child chunk）就是把 Excel 中“一行业务记录”转成能让向量检索与 LLM 都看得懂的最小语义单元。它既要携带行内全部有效信息，又不能冗余到超出模型窗口。

子块典型 Markdown／JSON 结构：

 1## 模块: 支付结算
 2**功能ID**: PAY-001 
 3**功能名称**: 创建收款单 
 4**功能类型**: 核心 
 5**COSMIC FP**: 6 
 6
 7{
 8 "module": "支付结算",
 9 "功能ID": "PAY-001",
10 "功能名称": "创建收款单",
11 "功能类型": "核心",
12 "COSMIC_FP": 6
13}

推荐生成流程（代码片段）:

 1import pandas as pd
 2from langchain.docstore.document import Document
 3from langchain.text_splitter import RecursiveCharacterTextSplitter
 4
 5df = pd.read_excel("functions_flat.xlsx", engine="openpyxl")
 6
 7child_docs = []
 8for idx, row in df.iterrows():
 9 module = row["模块"]
10 # —— 1) 行→Markdown
11 body = "\n".join(f"**{c}**: {v}"for c, v in row.items())
12 # —— 2) 写入 Document
13 child_docs.append(
14 Document(
15 page_content=f"# 模块: {module}\n{body}",
16 metadata={
17 "module": module,
18 "row_id": idx + 2, # Excel 行号（含表头补1）
19 "sheet": "功能清单"
20 }
21 )
22 )
23
24# 3) 控制长度，避免超窗口
25splitter = RecursiveCharacterTextSplitter(
26 chunk_size=2048, chunk_overlap=256
27)
28child_chunks = splitter.split_documents(child_docs)

标题行

行级子块一定写列名-值对
父块按需保存一次表头或仅存摘要

父子块生成策略

在 Excel → 向量库的 RAG 管道里，最省事、也最被 LangChain/LlamaIndex/Haystack 等工具链推荐的做法，就是 “在同一遍遍历中同时生成父块和子块，并用 module 或 parent_id 把两者关联起来”。这样既避免二次扫描，又保证所有子块天生带着正确的父信息，检索器便能先召回精确的行级子块，再顺着指针把对应的模块级父块自动补进上下文，实现“精召回 + 背景补全”的最佳组合。

一遍循环生成父子块的核心流程

步骤 0：展开合并单元格用 openpyxl 的 unmerge_cells 把合并区域拆开，再把左上角值填满整块；或用 pandas.ffill() 向下补齐。这样每行都能拿到正确的模块字段

步骤 1：遍历行 → 同时产出父块与子块

 1import pandas as pd
 2from langchain.docstore.document import Document
 3from langchain.text_splitter import RecursiveCharacterTextSplitter
 4
 5df = pd.read_excel("functions_flat.xlsx", engine="openpyxl").ffill()
 6parent_seen, parents, children = {}, [], []
 7splitter = RecursiveCharacterTextSplitter(chunk_size=2048, chunk_overlap=256) # 控长:contentReference[oaicite:7]{index=7}
 8
 9for idx, row in df.iterrows():
10 mod = row["模块"] # ① 遇到新模块先建父块
11 if mod notin parent_seen:
12 parent_seen[mod] = Document(
13 page_content=f"模块: {mod}",
14 metadata={"module": mod, "level": "parent"}
15 )
16 parents.append(parent_seen[mod])
17
18 body = "\n".join(f"**{c}**: {v}"for c, v in row.items()) # ② 行→Markdown，保留列名
19 child = Document(
20 page_content=body,
21 metadata={
22 "module": mod,
23 "parent_id": id(parent_seen[mod]), # 或直接存 module
24 "row": idx + 2
25 }
26 )
27 children.extend(splitter.split_documents([child])) # 行过长再递归切

父块只存简短摘要（如模块名、记录数），避免重复嵌入。
子块带齐列名-值对、行号及父引用，保证可追溯。社区经验贴也强调“列名+值”比裸值更利于语义检索

步骤 2：写入向量库只向量化子块，将 module 作为 partition key 或 metadata。父块可放旁路索引，或与子块一同存但不做向量化。

步骤 3：检索时自动拼接用 LangChain ParentDocumentRetriever、LlamaIndex AutoMergingRetriever 或 Haystack Auto-Merging Retriever：

先做向量检索拿到 k 个子块；
按 parent_id/module 查父块；
拼 “父摘要 + 命中子块(±近邻)” 送入 LLM。

检索流程

过滤：查询时先用 filter={“module”: <候选模块>} 做向量库精搜；Milvus 文档示例说明 filtered search 会先裁剪候选集再做 ANN，比全库检索快 2-4×
Auto-Merging：若一次命中同模块多行，LlamaIndex/Haystack 会把这些行和父摘要合并，避免窗口碎片化

注意事项

其他 chunking 策略

基于工作表和基于行的分块
基于列的拆分
混合与滑动窗口技术

用于 Excel 分块的工具和库

pandas

Python 的 pandas 库是许多 Excel 处理任务的核心，为读取 Excel 文件提供了强大的分块支持。 read_excel() 函数的 chunksize 参数允许进行内存高效、固定大小的分块

openpyxl

对于更复杂的 Excel 结构，openpyxl 库提供了对 Excel 文件解析的粒度控制，使其适用于基于内容的分块方法，能够有效处理合并单元格、公式和其他非标准元素。

xlrd

xlrd 库虽然主要针对较旧的.xls 格式，但对于遗留系统仍然具有相关性，并提供快速解析功能，在混合分块方法中，当速度至关重要时，这些功能非常有用。

RAG 系统文本切分：从固定长度到智能检索的六种方法解析

Mon, 02 Jun 2025 03:18:54 +0000

一、固定大小切分（Fixed-size chunking）

优势

顾名思义且容易实现。由于直接分割可能会破坏语义流程，建议在两个连续的片段之间保持一些重叠。

劣势

破坏语义结构：固定大小切分可能在句子或段落中间进行切分，导致语义信息被割裂，影响模型对文本的理解。
上下文信息丢失：由于切分不考虑文本的语义边界，相关信息可能被分散到不同的块中，导致模型在处理时缺乏必要的上下文支持。
缺乏灵活性：固定大小切分无法适应不同文本结构的变化，对于结构复杂或格式不一致的文档，可能导致切分效果不佳。
影响检索效果：在基于检索的生成任务中，固定大小切分可能导致相关信息被分散，降低检索的准确性和生成结果的质量。
处理长文本的挑战：对于包含长句子的文本，固定大小切分可能无法完整保留句子信息，影响模型的理解和处理能力。

缺点较多，不建议在大多数真实生产场景中使用。

二、语义切分（Semantic chunking）

原理概述

语义分块的核心思想是通过计算相邻句子的嵌入向量之间的相似度，识别语义上的断点，从而将文本划分为语义连贯的块。具体步骤包括：

句子分割：将文本按标点符号（如句号、问号等）分割成句子。
嵌入计算：使用嵌入模型（如 OpenAI Embedding）计算每个句子的向量表示。
相似度计算：计算相邻句子之间的语义相似度。
断点识别：当相邻句子的相似度低于设定阈值时，认为存在语义断点，进行分块。
块生成：将相似度高的句子合并为一个语义块。

这种方法旨在确保每个块内部的语义连贯性，从而提高检索和生成的准确性。

优势

语义完整性：通过识别语义断点，避免将相关内容分割到不同的块中，保持信息的完整性。
提高检索准确性：语义连贯的块有助于向量检索系统更准确地匹配用户查询，提高检索效果。
减少冗余信息：避免将无关信息混合在一个块中，减少噪声干扰。

劣势

计算成本高：需要计算大量句子之间的相似度，计算资源消耗大，处理速度较慢。
实现复杂：涉及嵌入计算、相似度分析等步骤，算法实现相对复杂。
效果依赖数据类型：在某些数据集上，语义分块的效果可能不如固定大小分块或递归分块。

语义分块在保持文本语义完整性方面具有优势，适用于对语义连贯性要求高的任务，如复杂问答系统。然而，其高计算成本和实现复杂度使其在资源受限或对处理速度要求高的场景中不太适用。相比之下，递归切分方法实现简单、处理速度快，适用于结构清晰的自然语言文本。因此，选择合适的分块策略应根据具体任务需求、数据类型和可用资源综合考虑。

三、基于文档结构的切片（Document structure-based chunking）

文档结构化分块（Document Structure-Based Chunking）是一种利用文档自身结构进行内容切分的策略。其核心思想是根据文档的自然组织形式（如标题、段落、章节、函数等）进行分块，以保留语义完整性和上下文连贯性，从而提升检索和生成的效果。

“Document structure-based chunking”（基于文档结构的切分）不是按固定长度或句子切，而是“按逻辑块”划分内容，常见于 Word、PDF、HTML 等格式的企业文档处理中，尤其适合处理说明书、规约、设计文档的场景。

原理概述

文档结构化分块的基本原理是：

结构感知：识别文档中的结构元素（如 Markdown 的标题、HTML 的标签、代码中的函数或类等），并以这些元素作为分块的边界。
语义完整：确保每个分块在语义上是完整的，避免将相关内容拆分到不同的块中。
上下文保留：通过保留文档的结构信息，维护内容之间的逻辑关系，增强模型对上下文的理解。

例如：在处理包含 Markdown 格式的文档时，可以使用 LangChain 提供的 MarkdownHeaderTextSplitter 类，根据标题层级（如 #、##、###）进行分块，从而保留文档的层次结构。

原理解析

1. 结构识别

从文档中提取结构元素，包括但不限于：

标题层级（如 H1/H2/H3、1.、1.1、1.1.2）
段落、表格、列表、分隔线
样式信息（加粗、缩进、字号、字体）
页面结构（页眉页脚、分页、目录）

这些结构在不同文档格式中的表现形式不同，例如：

Word：段落样式 + Outline Level
PDF：字体大小、粗细、缩进等视觉特征
HTML：DOM 节点层级

2. 结构驱动的切分逻辑

常见策略：

按每一个小节（如 1.1、1.2.1）作为一个 chunk，或多个小节合并为一个 chunk
同一标题下的所有段落视为一个逻辑块
若小节内容过多，则再结合递归切分或 token 限制切分

关键不是按“多少 token”切，而是“从属于哪个结构单元”切。

3. 结构标签保留（可选）

切分后的 chunk 还可保留其结构标识，如：

1{
2 "chunk": "本系统支持 7 层安全防护措施……",
3 "section": "2.3 安全架构设计"
4}

这便于：

检索时进行 rerank
LLM 回答时增强上下文定位感（结构提示）

举个例子:

给定这样一段 Word 文档内容：

11. 系统概述
2 介绍系统的设计目标与背景。
32. 功能模块
4 2.1 用户管理
5 包括登录、注册、权限分配等功能。
6 2.2 设备管理
7 支持设备的接入、控制与监控。

Structure-based Chunking 结果可能是：

Chunk 1: 1. 系统概述介绍系统的设计目标与背景。
Chunk 2: 2.1 用户管理包括登录、注册、权限分配等功能。
Chunk 3: 2.2 设备管理支持设备的接入、控制与监控。

docx2python 示例：

示例目录：

我们将把 Word 文档解析成如下结构：

 1[
 2 {
 3 "id": "1",
 4 "title": "1. 系统概述",
 5 "level": 1,
 6 "content": "……正文内容……"
 7 },
 8 {
 9 "id": "1.1",
10 "title": "1.1 功能模块",
11 "level": 2,
12 "content": "……正文内容……"
13 },
14 {
15 "id": "2",
16 "title": "2. 技术架构",
17 "level": 1,
18 "content": "……正文内容……"
19 }
20]

完整代码：解析 Word 文档结构和正文内容

 1from docx2python import docx2python
 2import re
 3import json
 4
 5def get_level_and_id(title: str):
 6 """
 7 从标题行中提取编号和层级（例：1.2.3 → level 3）
 8 """
 9 match = re.match(r"^(\d+(\.\d+)*)(\s+|$)", title.strip())
10 if match:
11 id_str = match.group(1)
12 level = id_str.count(".") + 1
13 return id_str, level
14 returnNone, None
15
16def parse_docx_structure(docx_path: str):
17 doc_result = docx2python(docx_path)
18 body = doc_result.body
19
20 parsed_chunks = []
21 current_chunk = None
22
23 for section in body:
24 for para_group in section:
25 for para in para_group:
26 text = para.strip()
27 ifnot text:
28 continue
29
30 # 如果段落以编号开头，视为新段落标题
31 id_str, level = get_level_and_id(text)
32 if id_str:
33 # 存储上一段内容
34 if current_chunk:
35 parsed_chunks.append(current_chunk)
36
37 current_chunk = {
38 "id": id_str,
39 "title": text,
40 "level": level,
41 "content": ""
42 }
43 else:
44 # 不是新段落标题，加入当前内容
45 if current_chunk:
46 current_chunk["content"] += text + "\n"
47 else:
48 # 文档开头没有编号，强行起一块
49 current_chunk = {
50 "id": "",
51 "title": "",
52 "level": 0,
53 "content": text + "\n"
54 }
55
56 if current_chunk:
57 parsed_chunks.append(current_chunk)
58
59 return parsed_chunks
60
61# 示例使用
62chunks = parse_docx_structure("example.docx")
63
64# 美观打印输出
65for chunk in chunks:
66 print(f"\n=== {chunk['id']} ({chunk['title']}) ===")
67 print(chunk["content"])
68
69# 可选：保存为 JSON
70with open("parsed_chunks.json", "w", encoding="utf-8") as f:
71 json.dump(chunks, f, ensure_ascii=False, indent=2)

在实际应用中，可以根据文档的格式选择合适的分块工具和方法：

Markdown 文档：使用 MarkdownHeaderTextSplitter，根据标题层级进行分块。
HTML 文档：使用 HTMLHeaderTextSplitter，根据 HTML 标签（如 <h1>、<h2>）进行分块。
代码文件：使用 PythonCodeTextSplitter 等工具，根据函数或类的定义进行分块。
表格数据：将表格内容格式化为模型易于理解的形式（如 HTML 的 <table> 标签、CSV 格式等），以保留表格的结构信息

这些工具通常会在分块的同时添加元数据（如标题、层级信息等），以便在后续的检索和生成过程中提供更丰富的上下文。

优势与适用场景

优势：

语义完整性强：每个分块通常对应一个完整的主题或功能单元，便于模型理解。
上下文清晰：保留了文档的结构信息，增强了内容之间的逻辑关系。
检索效果好：结构化的分块有助于提高向量检索的准确性。

适用场景：

结构清晰的文档，如技术文档、API 文档、法律文本等。
需要保留文档层次结构的应用，如知识库问答系统、文档摘要生成等。

注意事项:

文档结构不清晰时效果有限：对于结构混乱或缺乏明显结构的文档，结构化分块可能无法发挥优势。
块大小不均：不同结构单元的长度可能差异较大，需结合其他分块策略（如递归分块）进行优化。
实现复杂度较高：需要根据不同的文档格式设计相应的解析和分块逻辑。

文档结构化分块是一种有效的分块策略，特别适用于结构清晰、层次分明的文档。在实际应用中，可以结合其他分块方法（如递归分块、语义分块）进行混合使用，以获得更好的效果。

四、递归切分（Recursive Splitting）

“

实际上递归切分（Recursive Splitting）也是固定大小文本切块

在 RAG（Retrieval-Augmented Generation）系统中，递归切分（Recursive Splitting）是一种常用的文本分块策略，旨在将长文本有效地划分为适合处理的小块（chunk），以便后续的嵌入、检索和生成任务

工具：RecursiveCharacterTextSplitter (LangChain)
参数建议：
chunk_size=512 （适合多数 Embedding 模型）
chunk_overlap=128 （平衡上下文连贯性与冗余）
separators=["\n\n", "\n", "。", "？", "！", "；", "..."]（中文场景优化分隔符）
优势：先按大结构（标题）切，再按段落/句子细化，避免硬切关键信息。

原理概述

递归切分的核心思想是使用一组预定义的分隔符（如段落符、句号、空格等）按层次递归地将文本拆分成更小的块，直到每个块的长度满足设定的要求。

具体步骤如下：

初步切分：使用第一个分隔符（例如换行符 \n）对文本进行初步切分。
检查块大小：对于每个切分得到的块，判断其长度是否超过设定的最大块大小（chunk_size）。
递归处理：如果某个块的长度仍然超过 chunk_size，则使用下一个分隔符（例如句号。）对该块进行进一步切分。
继续递归：重复上述过程，依次使用预定义的分隔符列表中的下一个分隔符，直到所有块的长度都不超过 chunk_size，或者无法再进行切分。
合并块（可选）：在某些实现中，如果相邻的文本块合并后长度不超过 chunk_size，则可以将它们合并，以确保块的长度尽可能接近 chunk_size，同时保留上下文完整性。

这种方法的优点在于它能够尽量保留文本的语义结构，例如段落和句子边界，从而在保持上下文连贯性的同时，生成大小合适的文本块。

示例（LangChain）：

LangChain 提供了 RecursiveCharacterTextSplitter 类来实现递归切分。以下是一个使用示例：

 1from langchain.text_splitter import RecursiveCharacterTextSplitter
 2text_splitter = RecursiveCharacterTextSplitter(
 3 chunk_size=200,
 4 chunk_overlap=50,
 5 length_function=len,
 6 separators=["\n", "。", " ", ""]
 7)
 8text = "..." # 待处理的文本
 9texts = text_splitter.create_documents([text])
10for doc in texts:
11 print(doc)

在这个示例中：

chunk_size=200：设置每个文本块的最大长度为 200 个字符
chunk_overlap=50：设置相邻文本块之间的重叠长度为 50 个字符，以保留上下文
separators=["\n", "。", " ", ""]：定义了分隔符的优先级顺序，依次为换行符、句号、空格和空字符串。

这种方式确保了文本在切分时尽量保持语义的完整性和上下文的连贯性。

优势

保持语义结构：递归切分优先使用自然语言中的分隔符（如段落、句子等）进行切分，有助于保留文本的语义结构，减少信息碎片化的风险。
灵活的分块大小：通过递归使用不同的分隔符，能够根据文本的实际结构动态调整分块大小，适应不同长度和结构的文本。
适用于多种文本格式：递归切分方法适用于多种文本格式，包括自然语言文本、Markdown、HTML 等，能够处理结构复杂或层次分明的文档。
减少上下文割裂：通过在相邻文本块之间引入重叠部分（chunk_overlap），有助于保留上下文信息，提高模型对文本的理解能力。

适用场景

自然语言文本：如新闻文章、博客、书籍等，文本结构清晰，适合使用递归切分方法。
结构化文档：如 Markdown、HTML 等，具有明确的结构层次，递归切分能够有效地保留其结构信息。
需要保持语义完整性的任务：如问答系统、摘要生成等，对文本的语义连贯性要求较高，适合使用递归切分。

劣势

处理速度较慢：递归切分需要多次遍历文本，尤其是在处理大型文档时，可能导致处理速度较慢。
块大小不一致：由于依赖于自然语言的分隔符，生成的文本块大小可能不一致，这可能影响后续的处理效果。
计算资源消耗大：多次递归切分和合并操作可能导致较高的计算资源消耗，尤其是在大规模数据处理时。
对文档结构依赖强：递归切分依赖于文档的结构清晰度，对于结构不明确或格式混乱的文档，效果可能不佳。

不适用场景

结构化数据（如 Excel 表格）：Excel 表格中的数据通常以行和列的形式组织，递归切分无法有效保留其结构和语义信息。
代码或标记语言文档：对于包含代码块或标记语言（如 HTML、Markdown）的文档，递归切分可能会破坏其语法结构，影响后续处理。
多语言或混合语言文档：在处理包含多种语言的文档时，递归切分可能无法正确识别和处理不同语言的分隔符，导致切分效果不佳。
对块大小有严格要求的应用：某些应用对输入块的大小有严格限制，递归切分生成的不一致块大小可能不满足这些要求。

五、句子窗口检索（Sentence-Window Retrieval）

准确地讲，Sentence-Window Retrieval（检索期再扩窗）不是切片方式，而是检索策略 —— 先以“单句 chunks”建索引，命中后再把前后 N 句拼回去给 LLM。

原理概述

传统的 RAG 系统通常将文档按固定长度或段落进行切分，并对每个块进行向量化处理。然而，这种方法可能导致语义相关的信息被切割，影响检索效果。

句子窗口检索通过以下步骤优化这一过程：

按句子切分文档：将文档按句子进行切分，每个句子作为一个最小的检索单元。
构建句子窗口：对于每个句子，记录其前后若干个句子，形成一个“窗口”。这个窗口包含了目标句子及其上下文信息。
向量化处理：仅对目标句子进行向量化处理，而将其窗口信息作为元数据存储。
检索与生成：在检索阶段，根据用户查询与句子向量的相似度，找到最相关的句子，并将其对应的窗口信息提供给语言模型，以生成更准确的答案。

这种方法结合了细粒度的检索和丰富的上下文信息，提升了检索的精确度和生成的质量。

示例（LlamaIndex）

在 LlamaIndex 中，可以通过 SentenceWindowNodeParser 实现句子窗口检索： from llama_index.node_parser import SentenceWindowNodeParser

1node_parser = SentenceWindowNodeParser.from_defaults(
2 window_size=3,
3 window_metadata_key="window",
4 original_text_metadata_key="original_text",
5)

window_size=3：表示窗口包含目标句子前后各 3 个句子，共 7 个句子。
window_metadata_key 和 original_text_metadata_key：用于在元数据中标识窗口内容和原始句子

在检索阶段，可以使用 MetadataReplacementPostProcessor 将检索到的句子替换为其对应的窗口内容，提供给语言模型进行生成。

LlamaIndex 的 SentenceWindowRetriever 实践显示，对长段落文档回答的 F1 明显提升。
常用窗口：中心句 ± 3 句；别忘了把原句位置做 metadata，方便精确引用。

优势

提高检索精度：通过细粒度的句子级检索，提升了与查询的匹配度。
丰富上下文信息：窗口机制提供了更完整的上下文，有助于语言模型生成更准确的答案。
灵活的窗口大小：可以根据具体需求调整窗口大小，以平衡上下文信息量和模型处理能力。

适用于需要高精度检索和丰富上下文支持的场景，如问答系统、文档摘要等。

注意事项

窗口大小的选择：窗口过小可能导致上下文不足，过大则可能引入噪声信息。需要根据具体任务进行调整。
计算资源消耗：虽然只对目标句子进行向量化处理，但在检索和生成阶段，仍需处理较大的上下文窗口，可能增加计算负担。
模型输入限制：需要注意语言模型的输入长度限制，避免窗口内容过长导致截断。

六、自动合并检索（Auto-merging retrieval）

Auto-merging Retrieval（自动合并检索）本质上是一种检索策略，而非单纯的 chunk（文本切分）方法。要实现这一策略，确实需要配合特定的 chunk 策略，尤其是层次化的 chunking（Hierarchical Chunking）。

我们前文说的 “Document structure-based chunking”（基于文档结构的切分）就属于“Hierarchical Chunking”（层次化切分）策略的一种。

原理概述

自动合并检索的核心思想是将文档划分为多个层次的块（chunk），形成父子关系的树状结构。在检索过程中，如果多个相关的子块属于同一个父块，系统会自动将这些子块合并为其父块，从而提供更完整的上下文信息给大语言模型（LLM）

实现步骤

文档层次化拆分：使用如 LlamaIndex 的 HierarchicalNodeParser 或 Haystack 的 HierarchicalDocumentSplitter，将文档按预设的块大小（如 2048、512、128）递归拆分，构建出多层级的节点结构。
索引构建：将最小的叶子节点（最小块）进行向量化，并存入向量数据库中，供后续检索使用。
检索与合并：

在用户查询时，系统首先检索与查询最相关的叶子节点。
如果检索到的叶子节点中，有多个属于同一个父节点，并且超过设定的阈值（例如，超过该父节点子节点数量的50%），则系统会自动将这些子节点合并为其父节点，作为最终的检索结果返回

优势

增强上下文完整性：通过合并相关的子块，提供更连贯的上下文信息，减少信息碎片化。
提高生成质量：更完整的上下文有助于大语言模型生成更准确、相关性更高的回答。
降低幻觉风险：提供更全面的信息，减少模型因上下文不足而产生的错误回答。

注意事项

合理设置层次结构：根据文档的结构和内容，选择合适的 chunk 大小和层数，避免层次过多或过少影响检索效果。
调整合并阈值：根据具体应用场景，设置合适的合并阈值，确保在需要时合并相关子块，同时避免引入不相关的信息。
利用元数据管理父子关系：在构建层次结构时，确保每个子块都包含其父节点的引用信息，以便在检索时能够正确合并。

Document structure-based chunking 结合 Auto-merging Retrieval

要将“基于文档结构的切分”（Document Structure-Based Chunking）与“自动合并检索”（Auto-merging Retrieval）结合应用于 RAG（Retrieval-Augmented Generation）系统，可以按照以下步骤进行开发：

1 基于文档结构的层次化切分

目标：利用文档的结构信息（如标题、段落、列表等）进行多层次的切分，构建父子关系的树状结构。

实现方法：

使用工具：可以使用如 LlamaIndex 的 HierarchicalNodeParser 或 Haystack 的 HierarchicalDocumentSplitter。这些工具允许根据文档结构进行层次化切分。
设置参数：
block_sizes：定义每一层的最大块大小，例如 {2048, 512, 128} 表示父块最大为 2048 个单位，子块最大为 512 个单位，叶子节点为 128 个单位。
split_by：指定按何种单位进行切分，如按词（“word”）或句子（“sentence”）。
构建层次结构：通过上述工具和参数设置，将文档切分为多个层次的块，形成父子关系的树状结构。

2 构建向量索引与文档存储

目标：将最小的叶子节点进行向量化，并存入向量数据库中，同时保留父节点的信息以供后续合并使用。实现方法：

向量化叶子节点：使用如 OpenAI 的 text-embedding-3-small 或 SentenceTransformers 等模型，对叶子节点进行向量化。
存储向量：将向量化后的叶子节点存入向量数据库中，如 FAISS、Pinecone、Weaviate 等。
保留父子关系：在存储过程中，保留每个叶子节点与其父节点之间的关系信息，以便在检索时进行合并。

3 配置自动合并检索器

目标：在检索过程中，根据设定的阈值自动将相关的子块合并为其父块，提供更完整的上下文信息。实现方法：

使用工具：可以使用如 Haystack 的 AutoMergingRetriever 或 LlamaIndex 的 AutoMergingRetriever。
设置参数：
threshold：设定合并的阈值，例如 0.5 表示当超过 50% 的子块被检索到时，合并为父块。
document_store：指定包含父节点的文档存储。
检索流程：
根据用户查询，检索与查询最相关的叶子节点。
统计被检索到的叶子节点中，属于同一父节点的数量。
如果某个父节点下的被检索到的子节点数量超过设定的阈值，则将这些子节点合并为其父节点，作为最终的检索结果返回。

总结

在构建基于大语言模型（LLM）的检索增强生成（RAG）系统时，文本分块策略的选择对系统性能和生成质量具有决定性影响。本文深入探讨了六种主流的文本分块方法，分别是：固定大小切分、语义切分、基于文档结构的切分、递归切分、句子窗口检索和自动合并检索。以下是对这些方法的综合比较与应用建议：

1. 固定大小切分（Fixed-size Chunking）

优势：实现简单，计算效率高，适用于对语义完整性要求不高的场景。
劣势：可能破坏语义结构，导致上下文信息丢失，影响模型理解和检索效果。
应用建议：适用于结构简单、对语义连贯性要求不高的文本，如短消息、日志等。

2. 语义切分（Semantic Chunking）

优势：保持语义完整性，提高检索准确性，减少冗余信息。
劣势：计算成本高，实现复杂，效果依赖于数据类型。
应用建议：适用于对语义连贯性要求高的任务，如复杂问答系统、法律文档分析等。

3. 基于文档结构的切分（Document Structure-based Chunking）

优势：保留文档的层次结构，增强上下文理解，提高检索效果。
劣势：对文档结构依赖强，块大小可能不均，需结合其他策略优化。
应用建议：适用于结构清晰的文档，如技术文档、API文档、法律文本等。

4. 递归切分（Recursive Splitting）

优势：灵活适应不同文本结构，保持语义结构，减少上下文割裂。
劣势：处理速度较慢，块大小不一致，计算资源消耗大。
应用建议：适用于自然语言文本和结构化文档，需在处理速度和语义完整性之间权衡。

5. 句子窗口检索（Sentence-Window Retrieval）

优势：提高检索精度，丰富上下文信息，灵活的窗口大小。
劣势：窗口大小选择需谨慎，计算资源消耗较高，需注意模型输入限制。
应用建议：适用于需要高精度检索和丰富上下文支持的场景，如问答系统、文档摘要等。

6. 自动合并检索（Auto-merging Retrieval）

优势：增强上下文完整性，提高生成质量，降低幻觉风险。
劣势：需合理设置层次结构和合并阈值，依赖元数据管理父子关系。
应用建议：适用于结构清晰、层次分明的文档，结合其他分块方法使用效果更佳。

在实际应用中，选择合适的文本分块策略应根据具体任务需求、数据类型和可用资源综合考虑。对于结构清晰的文档，建议优先采用基于文档结构的切分方法，并结合递归切分优化块大小；对于对语义连贯性要求高的任务，可采用语义切分方法；对于需要高精度检索和丰富上下文支持的场景，可采用句子窗口检索或自动合并检索策略。此外，根据实际情况以上 chunk 策略不必拘泥于任何一种，可以混合使用。

算法 on 小盒子的技术分享

为什么 .tar.gz 要两个后缀

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

五、 结语：放过工程师，也放过企业自己

全程0人工写代码！干掉低级码农的不是大模型

全程0人工写代码！干掉低级码农的不是大模型

1 极致标准化的预热沙盒（Devboxes）

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

3 极其克制的上下文投喂：规则文件与 Toolshed

4 反馈左移（Shifting Feedback Left）：极速纠错循环

给我的启示

参考

AI 模型推理平台架构设计与实践

一、背景

为什么要搞推理平台

为什么要自己部署、运行、维护模型呢？ 全部用 API 不行吗？

一定要有 GPU （显卡资源）吗？

二、资源规划与集群架构

不止 k8s

KServe

KServe 架构

vLLM 和 Triton

三、部署思路

架构

1. 整体链路是谁在做自动扩缩容？

2. enable-scale-to-zero: “true” 的含义是什么？

3. 单模型 多 Pod ，如何占多机多卡？

面临的问题

解决办法

共享 GPU 技术

请求流 & 监控流（两条主链路）

推理请求链路（从客户端到 vLLM）

监控链路（业务 + GPU）

四、环境搭建步骤

需要安装的软件、版本及顺序

安装步骤 SOP

第 0 步：准备工作

第 1 步：安装 NVIDIA GPU Operator (v24.9.1)

第 2 步：安装 Kube-Prometheus-Stack (v61.9.0)

第 3 步：安装 Cert-Manager (v1.15.3)

第 4 步：安装 Istio (v1.22.6)

第 5 步：安装 Knative Serving & Net-Istio (v1.15.1)

第 6 步：安装 KServe (v0.14.1)

第 7 步：配置 vLLM Runtime (关键)

第 8 步：为 GPU 调度开启 Knative 的 nodeSelector / tolerations

第 9 步：Istio Sidecar 注入策略（避免影响 GPU Operator 和监控）

第 10 步：安装 MinIO（可选）

第 11 步：安装 Loki 和 Promtail

最终验证

验证 GPU Operator & GPU metrics 是否正常

轻量级测试

完整测试（triton + vllm）

六、基于 Argo 的 CI / CD

Argo 跟 Kubernetes 是什么关系？

部署层级

实践

实操 for Triton（预演）

实操 for vLLM（预演）

七、如何衡量平台是否成功？

维度一：性能与延迟 (Performance & Latency) - “我们的服务快不快？”

维度二：成本与效率 (Cost & Efficiency) - “我们的钱花得值不值？”

维度三：稳定性与可用性 (Stability & Availability)- “我们的服务稳不稳？”

今日 AI 情报

当“刷分”不再性感：为什么说姚顺雨的“AI下半场”是我们每个人的必修课？

引言

作者简介

概览

教育与经历

代表性研究与贡献

近期动态（2025 年 9 月）

原文和翻译

原文

翻译

上半场

那个秘方

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己

为什么要自己部署、运行、维护模型呢？全部用 API 不行吗？

3. 单模型多 Pod ，如何占多机多卡？

三、基于文档结构的切片（Document structure-based chunking）