最新

我尝试使用基准测试的方式来评估一个 AI 智能体。<p>结果它以我意想不到的方式失败了。<p>大多数失败并非源于模型质量问题，而是系统层面的问题。以下是一些来自小型测试套件的例子：<p>- 工具调用中的 URL 链接失效 → 分数降至 22<p>- 智能体在云环境中调用本地主机 → 卡在 46 分<p>- 真实的 CVE 漏洞被标记为幻觉 → 评估问题，而非模型问题<p>- Reddit 屏蔽请求 → 外部依赖失败<p>- 生产环境中 API 密钥缺失 → 静默失败<p>每次运行都会暴露一个真实的 bug，但并非我最初试图衡量的类型。<p>令我惊讶的是，评估智能体不仅仅是评估输出结果。它还涉及到验证整个系统：工具、环境、数据访问，以及智能体与所有这些的交互方式。<p>换句话说，大多数失败模式更像是软件 bug，而不是 LLM 的错误。<p>这让我认为，智能体的评估循环应该更像软件测试，而不是基准测试： - 可重复的测试套件 - 明确的通过/失败标准 - 回归检测 - 根本原因分析<p>否则，很容易将失败归咎于模型，而实际上它们来自其他地方。<p>我最终构建了一个小工具来规范这个流程，但对我来说，更大的收获是，与标准基准测试相比，现实世界中的智能体评估实际上是多么混乱。<p>很好奇其他人是如何处理这个问题的，尤其是在生产环境中。

我是 Rufus，Flowershow 的创始人之一。我们热爱 Markdown，并将其广泛应用于网站、文档和知识库的创建。此外，现在 AI 也在各处使用它。<p>我们厌倦了每次想分享文件或上线网站时都要面对的框架/配置/部署开销。<p>所以我们构建了我们想要的东西。文件输入，网站输出。我们的目标是成为“内容领域的 Vercel”——让部署（Markdown）内容像 Vercel 对 JS 那样快速、无缝和简单。<p>命令行工具，外加你可以连接到 GitHub 仓库，通过插件使用 Obsidian，或者拖放文件。<p><pre><code> npm i -g @flowershow&#x2F;publish publish .&#x2F;my-notes # → https:&#x2F;&#x2F;your-site.flowershow.app 几秒钟内上线 </code></pre> Flowershow 是<i>完全托管的</i>——无需服务器、构建管道或 CI/CD。指向一个 Markdown 文件夹，即可获得一个 URL。<p>支持完整的 Obsidian 语法：维基链接、标注、图表视图、frontmatter<p>GFM、Mermaid、LaTeX：原生渲染图表和数学公式<p>通过 Tailwind 和 CSS 变量实现主题：开箱即用的 Tailwind。无需构建步骤即可自定义<p>支持 HTML：使用 HTML、图像等。<p>约 7000 次 Obsidian 插件安装，1400 名用户，1100 个网站。个人使用永久免费。高级版（每月 5 美元）增加了自定义域名、搜索和密码保护。<p>而且它是开源的：<a href="https:&#x2F;&#x2F;github.com&#x2F;flowershow&#x2F;flowershow" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;flowershow&#x2F;flowershow</a><p>欢迎试用，并告诉我们您的想法以及我们可以改进的地方