分类标签归档：LLM
导读：这篇文章系统讲述如何从零设计一个"用 AI 测 AI"的 Agent 评测平台，覆盖五类用户角色、十大核心模块与"一个 Agent 一个 Project"的架构定位，并给出了从技术选型到 MVP 路径的完整落地参考。最有价值的设计是分层断言体系——L1 请求级（Tool 调用、参数、副作用）、L2 行为级（结构、业务规则）、L3 结果级语义判定，原则是"能不用 LLM 判的就不用 LLM"；同时强调 AI Judge 必须配人工校准闭环（与 Golden Set 人工标注的一致率 ≥85% 作为发布门禁）。适合要搭建
导读：文章分享一套对话式 AI 机器人评测体系的演进路径：先以 100 道固定考卷（含正向与负向用例、80 分及格）建立横向可比基线，再引入 LLM 自动评分，最终扩展为覆盖全业务环节的基准测试（抽样、提问变异、安全、双盲评分）；平台以"批次—用例"组织，用准确率/精确率双指标与多模型同卷对比，让模型选型与调参"靠数据不靠拍脑袋"。适合负责对话机器人/大模型应用质量评测与模型选型的团队，面试官可借此考察候选人对评测指标口径和自动化评测体系的理解。
对话式 AI 机器人上线之后，一个绕不开的问题随之而来：怎么持续评估它的质量？模型要选型、要调
导读：这篇文章给出用 Langfuse 对生产 LLM 应用做错误分析的六步闭环：事件归一化 → Skill 归因 → 根因分类矩阵 → 时间趋势对照发布 → 僵尸会话/重复请求去重 → P0/P1/P2 分级修复。几个关键量级值得记住：同一失败会在多个观测上重复呈现约 2.9 倍、单条僵尸会话可占 48 小时失败总量近一半、框架级缺陷（思考模式字段未回传）约占失败四成五。适合做 LLM 应用线上故障排查与可观测性建设的后端/SRE 工程师，方法可直接复制。
分类：AI评测 ｜ 标签：LLM、可
在 LLM 质量保障的日常里，最常被问到的问题之一是："这个模型到底行不行？"
但"行不行"从来不是一个数字能回答的。同样是"MMLU 78 分"，few-shot 设成几？prompt 模板用什么？是不是 chat 格式？温度多少？有没有踩到测试集污染？——任何一项没对齐，跨团队、跨模型、跨版本的数字都不可比。
lm-evaluation-harness 就是为消灭这种"不可比"而生的。它是 EleutherAI 维护的 LLM 评测框架，也是 HuggingFace Open LLM Leaderboard 背后的评测引擎。这篇文章是我把它真正用进质量体系的实战笔记，不堆概念，只讲怎么跑、
导读：本文分析一个「本地校验全部通过、线上最后一步保存失败」的接口问题：根因不是后端，而是发送给保存接口的 config 参数被传成了 Python 字典对象（单引号、None、True/False）而非 JSON 字符串，表单编码后服务端解析失败并返回兜底错误。核心洞见是「本地文件正确 ≠ 实际发送体正确」，校验对象错位让校验再严格也拦不住；修法是新增「提交前 wire 自检」——在接受校验之后、真正发出之前校验实际请求体，并在工具层做序列化加固与请求原文回显。适合排查 LLM 工具调用参数序列化、接口契约与兜底文
导读：本文分享 Agent 技能平台（技能市场）AI 质量治理的设计与落地，用覆盖全生命周期的三条治理线——上架门禁（静态扫描 + 对话质检 + 自动修复引导）、发布审核与质检（分享超阈值自动触发人工审核）、运行期健康度（观测采样 + 四维评分 + 报告触达），并守住两条红线：机器结论永远只当审核输入、不当裁决，基础设施抖动不误伤作者内容。核心认知是把 LLM 当作"可编程、可约束、可验证"的推理组件，工程本质是"数据喂养、规则驯化、测试兜底"；案例包括把 LLM 门禁从发布关键路径改为"放行 + 异步质检 + 通知"以平衡
导读：本文解决"服务商只给 RPM/TPM 限流配额，业务却想知道能支撑多少用户与对话"的容量估算问题。核心方法是先用观测数据统计每轮对话的平均调用次数与 token 消耗，再按"容量 = min(RPM/每轮调用数, TPM/每轮token)"两个维度各除一次、取较小者；关键结论是长 prompt 场景下 token 维度几乎总是先撞墙（示意示例中 token 上限约 250 轮/分 vs 请求上限 2,500 轮/分），只看 RPM 会严重高估容量、上线后提早吃到 429。适合所有接入第三方 LLM API、需要做配额容
导读：这篇文章演示如何用 Langfuse 对生产 LLM 应用做耗时拆解：按端分层、全池随机抽样 80 条 trace，用"独占耗时"口径（父节点时长减去子节点）把 LLM、工具、Skill、框架规划各段分别量化。核心结论是大模型生成耗时占全链路 67.6%~95.9%，输入长度与耗时强正相关（r≈0.71）、多轮上下文累积让成本加速膨胀，超长尾多来自模型服务端抖动。适合做 LLM 应用性能优化与可观测性建设的工程师，采样与归因方法可复制到任何应用。
分类：AI评测 ｜ 标签：LLM、可观测性、Langfuse、性能分析
数据
导读：这篇文章复盘一轮 Agent Skill 优化，回答"AI 评审建议要不要照单全收"——结论是约 1/3 建议的例证与文件事实不符，采纳与否的唯一依据是"模型的运行时行为会不会因此出错"。文中给出五条可复用经验：工具边界收紧要全包同步、体例升级要扫旧口径残留、重复要人工复核、逆向内容按运行时价值裁剪、用工程手法兜底。适合做 Skill 质量治理与评估对比的工程师，可当作评审建议的核对清单使用。 分类：AI评测 ｜ 标签：Agent、Skill、优化复盘、LLM
导读：文章以"用 Trae/Cursor 从零开发 LLM 测试系统（FastAPI + React）"为案例，核心结论是 AI 编程的关键在"写提示"而非"写代码"：把大需求拆成接口结构→数据模型→前端组件→联调日志的可验证小任务，配以"角色 + 目标 + 要求 + 上下文 + 样例"的提示词模板，再靠 MVC 分层、统一日志、ORM 迁移与 AI code review 兜底质量，走完从架构设计到部署上线的全流程。适合尝试用 AI 辅助开发内部工具、或想评估候选人在 AI 编程实践中真实功底的工程团队。