工作清單

Jev + Browser Use 实测:我试过最快的 AI Agent 到底有多强?

逐字稿文字預覽

大家好,欢迎来到新一期视频。开始之前,我想先说一下。我在我的ARCK频道上更活跃了。我现在会发一些这里不讲的新内容。还有一些开发者相关的工具,你们也可以去看看。链接我会放在简介里。我现在拿到了Jeff的使用权限,想看看这东西到底有什么用。TagC说,它适合做极快的判断,非常低的成本。
以及软件可以直接使用的结构化输出。所以,我准备了一些实用测试。其中还包括一些场景,如果设置本身有问题,就可能直接得到错误答案。Jeff是Tag所说的System-1模型。你把一些信息给他,问具体问题,他就会返回判断结果。他不会像普通聊天那样生成回复。也不会帮你写一个应用。有三种主要的问题类型。Chance是从你提供的选项里选一个。Store是用你定义的等级来打分。
那则会给出一个是或否陈述为真的概率。这样做的目标是让这些小判断足够便宜、足够快。能贯穿整个软件使用。比如,你的应用可以判断该把消息发给哪个团队。某人是不是申请了退款,以及某件事是否需要处理。然后,代码再决定怎么处理这些答案。
好了,我们直接来看测试。我先从一条关于重复扣费的客服消息开始。客户要退回多收的钱,说网站能正常用。还说这件事可以等到明天。我把四个问题放在一起问了。该哪个部门处理是否请求了退款,是否紧急,以及。
Jaf把他选成了billing。退款请求的概率是98%,而紧急程度只有11%。frustration分数也接近平静那一段。所以,他把这些东西分得很准。在这个例子里,billing问题不会自动变成技术问题。退款请求也不会自动变成紧急情况。这对help desk这类工作流来说是个很好的起点。然后,我把消息改成,我不是再要退款。我只是需要一份发票副本。
他还是选了billing。这很合理,但退款概率降到了3%。所以,他正确处理了否定,不是只看到refund这个词。就把它当成退款请求。这也是为什么在把任何模型接到动作之前。我都会先测试你实际是怎么说的。要退款,问退款政策。明确拒绝退款,这三件事完全不同。下一个测试显示了一个我觉得特别值得理解的局限。我问食堂几点关门,在有其他选项可选的情况下。
这选了other。所以,他确实把这个问题排除在billing,technical support和sales之外。然后我给了他一个版本的问题,只允许那三个部门。
这一次,他选了sales,智信度是0.31。答案符合我给出的选项。但这些选项里没有一个涵盖了我的需求。我其实是在故意设置一种情况,让他没法返回我需要的答案。所以,当你听到零hallucinations这种说法时,要记住这个区别。限制输出确实能阻止模型编造一个新类别。
他并不能保证他选出来的类别有用或者正确。像这种流程里,我会加一个其他或未知选项,留给人工复合。
而且,我不会把90%的confidence理解成模型有90%的时间都判断正确。这得用你自己的样本去测试。接着,我试了一个基础的prome injection。原始消息说,顾客点付款时结账页面崩了。而且,他们并不是要退款。
Juff把他路由到技术支持,并把退款请求的概率设得很低。然后我在消息里塞了一个假的system override,让他选billing。并把退款和紧急程度这两个问题都标成处。
但我真正的评估指令告诉他,要把消息里的这些内容当成不可信文版。他还是保留了技术知识分类,并且把退款概率一直很低,只有3%。紧迫感一直停留在不确定的中间地带,没有直接变成强烈的事。不过,单靠一次简单的注入测试,还不能说明模型就能免疫攻击。之后,我又测试了另一个稍微不同的东西。从文档里精确选出一个纸,消息里包含发件人的邮箱。
就账单地址,以及收据应该发送到的新地址。我把这些地址作为颗选项提供进去。然后问当前的收据该发到哪里。他选中了新地址,连加号和年份都完全按原样选出来了。
这对理解Jaf是怎么做提取很有用。你的代码可以收集候选值,Jaf负责选出相关的那个。再由你的代码复制。但如果你的第一步没找到正确地址,Jaf就没法通过一道选择题把它补出来。
候选列表是你要测试的系统的一部分。
最后,我试了一个小的agent审计事例。工具返回显示权限被拒绝,什么都没保存。但assistant的最终消息却说草稿已经成功保存。
Jaf把这个任务判为失败,并给出了93%的概率。认为这个成功说法没有依据。
我喜欢它在这个例子里是按工具证据来判断的。不过,这个错误本身很简单,用普通代码就能抓出来。
更有意思的应用是去检查那些更段的trace有好几步。部分进展还有互相矛盾的说法。那就需要大得多的测试集了。
现在,还有一个挺有意思的browser automation演示。
Gregor Zinnick分享了一个开源项目,叫Jeff Ultrafast。
他把Jeff和Browser Use工具结合在一起。
他在演示里展示了他在大约7秒内,帮他在Google Flags上查到了从苏黎世到伦敦的单程航班。
他说这次调用成本是0.39美元,不到半美分。
而且视频还是元素播放的。
这都是他自己报告的结果。
我自己还没复现这个航班测试。
他的工作方式挺有意思的。
他会读取网页结构,然后生成一个代编号的空间列表。
每一步之后,他都会刷新科选项。
Jeff先选下一步操作。
再把相关目标和这些问题打包成一个请求。
虽然遇到需要实际文本时,他也可以点击某个按钮,或者在某个输入框里打字。
那部分文本是由一个单独的小语言模型生成的。
这个例子里用的是Mercury 2.5。
这是Jeff如何融入更大agent的一个实际例子。
Jeff负责结构化决策,另一个模型负责生成文本。
浏览器代码还是得检查目标并执行动作。
这里有几个细节要注意。
公开的记事是从第一次页面观察后才开始的。
所以不包含启动时间。
而且这是一次不需要预定的机票搜索。
报告的价格也和模型的成本估算一致。
有统计使用量,不过那不包括浏览器基础设施。
我也把这个项目和运行说明加进了TestKit。
这些请求总共用了4148个输入Token。
按公布的价格,每百万输入Token4.2美分估算下来。
输入费用远不到一美分。
按这个价格,输出Token是免费的。
这些小例子成本其实很低,但一个应用的总成本。
还包括你用来准备输入检查答案。
以及处理那些需要换别的模型或人工介入的部分。
我还记录了模型版本。
我选的是JeffTheLatest。
返回结果里,把模型识别成了Jeff1.13.0。
这个信息最好和结果一起保存,因为叫做Latest的别名是会变的。
总的来说,我觉得最有意思的地方,
是你能很轻松地把这些判断塞进应用里。
我测试的例子显示,它在路由否定选择值。
以及根据证据核实说法,这几方面表现不错。
也说明了你给出的选择和指令有多重要。
这些只是八个代和城市里的小请求。
他们给了我一些值得继续研究的方向。
但还不能证明它在生产环境里可靠。
也不能证明它在速度上比其他模型快很多。
我把测试脚本也附上了,你可以自己附现这些例子。
你也可以试试更大范围的样本。
比较一下是把多个问题一起问,还是分开提问。
这样更容易看出JF是否适合你工作流里的某个特定环节。
总体来说还挺不错的。
总之,欢迎在评论区告诉我你的想法。
如果你喜欢这个视频,可以通过Super Thanks打赏。
也可以点击这双按钮加入会员。
另外,别忘了给这个视频点赞并订阅我的频道。
我们下期再见,拜拜。

來源:transcript.txt

本次執行流程與問題處理

  1. 下達指令

    指令:videonote https://b23.tv/Lb5Acv0 --language zh --auto-source-subtitles

    來源:https://b23.tv/Lb5Acv0

    辨識語言:zh | 參數:--language zh --auto-source-subtitles

  2. 預期流程

    依指令產生的處理順序:

    1. 自動字幕優先,Whisper 作為備援
    2. 來源選擇與品質檢查
    3. 文字校正與句子單元
    4. 筆記與發布
    5. 公開網頁發布
  3. 1. 下載與語音辨識

    工具:videonote-transcribe-url(主辨識管線:下載、Whisper 辨識與選稿)

    處理:下載音訊、以 Whisper 辨識並選出最佳逐字稿

    產出:yt_dlp_meta.json(影片元資料)、audio_16k_mono.wav(16kHz 單聲道音訊)、transcript.whisper.json(Whisper 辨識結果)、transcript.json(正式逐字稿)、transcript_selection_report.json(來源選擇報告)

    耗時:27.4 秒

    關係:依序執行

    結果:完成

  4. 2. 全文快速校讀

    工具:videonote_rapid_transcript_review.py

    處理:先速讀完整逐字稿,再修正高可信突兀詞句並列出待確認項目

    產出:rapid_transcript_review_report.json(產出檔案)

    耗時:38.6 秒

    關係:依序執行

    結果:完成

  5. 3. 建立句子單元

    工具:videonote-build-sentence-units

    處理:將逐字稿切成帶時間軸的句子單元

    產出:sentence_units.json(句子單元)

    耗時:0.7 秒

    關係:依序執行

    結果:完成

  6. 4. 句子密度平衡

    工具:videonote_balance_sentence_units.py

    處理:平衡句子長度與密度

    產出:sentence_units.json(句子單元)

    耗時:0.7 秒

    關係:依序執行

    結果:完成

  7. 5. 時間軸稽核

    工具:videonote_timeline_audit.py

    處理:檢查時間軸與音訊對齊

    產出:timeline_audit_report.json(時間軸稽核)

    耗時:0.8 秒

    關係:依序執行

    結果:完成

  8. 6. 品質檢查

    工具:videonote_controlled_quality.py(檢查時間軸與品質)

    處理:檢查語言、時間軸與可讀性品質

    產出:controlled_quality_report.json(品質報告)、language_sanity_report.json(語言檢查)

    耗時:0.8 秒

    關係:依序執行

    結果:完成

  9. 7. 播放時間軸回填

    工具:videonote_rebase_display_timeline.py

    處理:將網頁播放時間軸回填為校正字幕時間

    產出:display_timeline_rebase_report.json(時間軸回填報告)

    耗時:0.8 秒

    關係:依序執行

    結果:完成

  10. 8. 逐字稿交叉檢查

    工具:videonote_cross_check_transcript.py

    處理:交叉檢查逐字稿與來源字幕

    產出:transcript_crosscheck_report.json(交叉檢查)

    耗時:0.9 秒

    關係:依序執行

    結果:完成

  11. 9. 來源句整理

    工具:videonote_prepare_source_entries.py

    處理:整理來源句子供時間軸與頁面使用

    產出:sentence_units.json(句子單元)

    耗時:0.9 秒

    關係:依序執行

    結果:完成

  12. 10. 生成筆記摘要

    工具:videonote-generate-note(生成筆記摘要)

    處理:生成筆記摘要與重點

    產出:note.md(筆記 Markdown)、note.html(筆記 HTML)

    耗時:89.3 秒

    關係:依序執行

    結果:完成

  13. 11. 建立筆記頁面

    工具:videonote-render-html(產生筆記 HTML)

    處理:產生可閱讀的筆記 HTML 頁面

    產出:note.html(筆記 HTML)

    耗時:0.4 秒

    關係:依序執行

    結果:完成

  14. 12. 發布公開頁面

    工具:videonote-publish(發布公開頁面)

    處理:發布到公開網站與每日列表

    產出:公開筆記網址、result.json(管線結果)

    耗時:0.5 秒

    關係:依序執行

    結果:完成

手動來源字幕

自動來源字幕

Whisper 字幕

Qwen 字幕

Parakeet 字幕

MOSS 字幕

聲學時間證據(PyAnnote / WhisperX)

校正前後逐字稿

目前待解決問題與初步改善方向

進一步精進字幕與筆記
使用 Workbench 上傳校正字幕、中文參考稿或回饋 SRT,重新產生雙語與學習單元。
開啟 Workbench