你已經讀過這段文字太多不同版本了,可能這週內就讀過:

「在當今快節奏的世界裡,AI 不只是工具,而是能帶來典範轉移的綜合體。讓我們深入這個變革性的領域,真正的魔法就在這裡發生。」

我在 Towards AI 的團隊現在幾乎所有內容都用 AI 起草:影片、課程、書籍、文章……成千上萬篇。我和我的團隊幾乎什麼都用 Claude,而我常常需要審閱的內容聽起來就完全是上面那種調調。

所以從 6 月開始,我一直在測量哪些模型真的能寫得像我。經過 9,050 份腳本後,令人驚訝的是,這些「垃圾文風」其實很容易修正。

測試設計

今年 6 月,我挑了 10 份自己的影片腳本,有些已公開,有些則刻意保留不用,以防資料汙染。我們四個人花了一個月、幾乎全職投入,大約 400 個小時,細修這些腳本,並把它們之所以有效的要素整理成(盡可能清楚且詳盡的)評分規準。

接著,我們測試模型在能取得我的語氣指南、敘事指南、輸出規則、過往範例、簡報摘要與研究資料的情況下,能否重新生成出像樣的內容。

之後,我們讓 4 個 LLM 評審根據我的最終版本與評分規準來打分每一份草稿:一個 GPT、一個 Claude、一個開源模型,最近還加上了 Jev。

到目前為止,我們已經測了 181 種組合,包括每一種思考等級,而且也打算持續測量之後推出的所有新模型。

但最重要的是,以下是我們在建立這個新基準、審閱數千份生成結果,以及反覆迭代評分規準後學到的事。

較少的垃圾感,不代表更好的寫作

我們前 15 名的配置在垃圾字樣檢查上都超過 90 分,所以在有詳細提示詞的情況下,像上面那種句子大致都已經能控制住。

如果你已經受不了垃圾文風,那在我們測過的 181 種模型裡,最乾淨的是 GPT-6 Astra 的最高努力模式:94.9 分。

不過還是要小心:這只是我們追蹤的其中一個指標。Astra 目前總排名第 62,因為它不像我:語氣與風格只有 82 分,而 Opus 有 90 分。整體來看,Claude 系列模型包辦了前 11 名。

我在反覆調整兩個模型時學到的重點是,刪掉幾個 Claude 式語氣很快就能修好。雖然煩人,但只要簡單改一輪就能解決。可是重建一種語氣就不是這麼回事了。那需要大量心力、重組文字、改寫例子……也因此目前我還是偏向用 Claude 來寫作。

最高努力模式只換來極少提升

Opus 5.5 的最高努力模式,是我們測過最好的寫作者,100 分滿分拿到 90.8 分。在 xhigh 模式下,它拿到 90.0 分,每份腳本只要 0.69 美元,而不是 2.75 美元。

這代表價格貴了 4 倍,分數卻只高不到 1%。我會選 xhigh,把最高努力模式留給少數每一句都很重要的作品。

便宜模型改變了工作單位

GLM-5.3 Flash 這個開源權重模型,每份腳本只要 1.5 美分,卻能拿到 88.2 分。Opus 5.5 的最高努力模式成本幾乎高出 190 倍,分數卻只高大約 3%。

這不只是代表用 GLM 生成相近的文字,成本幾乎便宜 200 倍。它的意思是,若用得好,你甚至可以用開源模型,以更低成本生成比 Claude 更好的結果。

我們也測量了不同生成結果之間的變異性。如果你用 GLM 生成 10 份草稿,挑出最好的一份,結果會和 Opus 5.5 非常接近,而且成本仍然便宜 20 倍。如果再加入一個強大的評審,配上好的評分規準,並且能把不同草稿中的段落合併,做出最好的「弗蘭肯斯坦式」草稿,理論上它應該能以更低成本產出比 Opus 5.5 更好的成果。

現在生成很便宜了,挑選才是難點。錢應該花在評審與篩選上,而不是生成上。

每個評審都有偏好的實驗室

和其他評審相比,我們的 GPT 評審會替 OpenAI 的草稿加 2.75 分,卻會替 Anthropic 的草稿扣 2.14 分。

DeepSeek 評審會替 DeepSeek 和 Kimi 加大約 1 分。

Claude 評審的偏差最小,只有其他評審的一半左右,不過它還是會給自己家模型加分,而且出人意料地更喜歡 Google。

Jev 算是相當中立,也稍微偏好 Gemini 系列,但它在評分時無法清楚說明理由,似乎讓它在我們的任務中一致性較差,或許是因為寫作更像是一種「系統 2」型的判斷。

沒有任何評審是完全中立的。要用評審團,永遠不要讓你自己寫作團隊所屬實驗室的模型成為唯一評分者。

如果是我,會這樣用 AI 寫作

選那個能讓你用最少修改就到位、而且不會讓你抓狂的模型,不是選那個寫出來最「驚艷」的模型。然後:

  1. 寫下很長、非常具體的指令:你的語氣、結構、規則。
  2. 提供該做的範例,也提供不該做的範例。把你討厭的字句明確列出,並用程式碼檢查草稿是否出現,而不是單靠提示詞。
  3. 加入你過去最好的作品,完整貼上,最好再附上它們為什麼好的細節。
  4. 用便宜的開源模型生成多份草稿。
  5. 讓另一個實驗室的高思考能力評審,根據清楚的規準挑出或合併最佳版本。
  6. 再跑一到兩輪由不同評審進行的審閱與編修。超過兩輪之後,我就沒看到太多幫助了。
  7. 最後一定要留一個人把關。就連 Opus 5.5 的草稿也需要這一步。

有一點要注意:這份測試衡量的是我在我自己的腳本上的語氣。這只是一個資料點,不是絕對真理。在你換任何工具之前,先用你自己的寫作來測試!建立這套評估流程非常有用,我們已經把它調整後用在許多客戶的客製任務上,成果都很好。

我會在 10 月 13 日星期二的演講中,公開完整基準 ToneBench,以及本文每個數字背後的方法(上午 10:40,Turing room — Evals Track)。歡迎來打招呼;我很樂意聊聊,也會持續改進這個基準。


原文出處:https://dev.to/dailycontext/what-9050-ai-written-scripts-taught-me-about-slop-1g5n


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝46   💬1  
739
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
📢 贊助商廣告 · 我要刊登