LifeSciBench 讓模型先過科研關

LifeSciBench 把生命科學模型評估拉回真實科研工作，重點是推理、知識整合和實驗設計。

我盯模型評測這件事很久了。一般 benchmark 跑得漂亮，大家就開始拍手，像是模型已經懂研究了。但我每次把它丟回真正的生命科學場景，就會冒出一堆毛病：論文看得像懂，其實抓不到重點；可以講機制，卻不會比對方法；回答很順，落地到實驗室就整個歪掉。這種落差我真的看膩了。你說你要做 research AI，結果連一個像樣的實驗設計都扛不住，那不叫研究助理，那叫會講話的幻覺機器。

這次把我拉進來的是一篇中文整理，《海外AI觀察日報｜2026-06-18》，裡面整理了 OpenAI 的 LifeSciBench。那篇沒有公開 star 數或觀看數，我就不亂掰。真正有意思的不是熱度，而是它把問題講白了：生命科學模型不能只會答題，得能碰科研工作本體。

一般評測最愛騙人，科研工作最不吃這套

OpenAI 發布 LifeSciBench，用於評估模型在生命科學任務中的能力邊界。該基準強調真實科研工作中的推理、知識整合和實驗設計相關能力，而不是只測通用問答。

翻譯一下就是：一個模型就算很會聊天，也不代表它能幫你做研究。生命科學場景要的不是漂亮句子，而是能不能把論文、機制、方法、限制條件和實驗目標串起來。這不是「懂不懂」，這是「能不能用」。

我之前看過不少團隊把模型拿去跑泛用 QA，分數很體面，然後就開始講「我們已經能做科研輔助」。結果一進到 lab workflow，問題立刻露餡：它會摘要，不會判斷；會補字，不會比較；會講結論，不會告訴你這個結論能不能信。這種評分方式最大的問題，就是把會說話誤認成會工作。

實操上，我會直接把評測題從「請回答這個問題」換成「請處理這個任務」。例如：

• 比較兩篇論文的實驗設計差異。
• 找出一個結論在什麼條件下可能不成立。
• 根據限制條件，提出下一步實驗。

只要題目一改，模型能不能真的幫忙就很明顯了。這也是 LifeSciBench 讓我覺得順眼的地方，它不是在幫模型洗白，而是在把模型拉回工作現場。

知識整合才是生命科學模型的真正考題

LifeSciBench 的重點之一是 knowledge integration。這個詞聽起來很學術，實際上很土：就是你不能只會背一篇論文，你得知道怎麼把多篇資料拼成一個能用的判斷。

生命科學最煩的地方就在這裡。機制、數據、方法、樣本條件、模型假設，全部都會互相打架。兩篇 paper 的結果不一致，不一定是誰錯，常常只是條件不同。會做研究的人知道要看 context；不會的模型就只會把句子接起來，接得像樣，錯得安靜。

我自己碰過最典型的狀況，是拿模型去整理一條 target pathway。它可以把每個名詞都講對，甚至還能排出一個看起來很順的敘述。但只要我追問：「這兩篇結果為什麼不同？」它就開始滑坡，講一些泛泛的可能性，完全沒有把 evidence 和 speculation 分開。那種回答很像一個很會裝懂的實習生，嘴很快，手很慢。

實操寫法我會這樣做：

• 做多來源題，不要只給單篇論文。
• 刻意放入互相矛盾的結果，看模型會不會解釋差異。
• 要求模型標出哪些是證據，哪些只是推測。

如果你的產品是給研究人員用，這一關比語氣自然重要太多。研究人員不缺順口溜，他們缺的是一個不亂攪局的判斷器。

實驗設計這關過不了，前面分數再高都白搭

我很在意 LifeSciBench 把 experimental design 放進來，因為這才是很多模型最容易翻車的地方。講機制很容易，設計實驗很難。前者是把話說完整，後者是要你知道怎麼證明自己沒在瞎猜。

設計實驗不是只會說「可以測一下」。你得知道 control 是什麼、confounder 是什麼、readout 怎麼選、樣本數夠不夠、結果出來要怎麼解讀。少了這些，模型給的就只是看起來合理的建議，離可執行還差很遠。

我以前看過一個 demo，模型對某個生物機制講得頭頭是道，最後被問一句「那你建議怎麼驗證？」它就開始空轉。這不是小瑕疵，這是整個用途直接打折。因為科研不是寫作文，不能只交一段漂亮結論。

如果我自己要做評測，我會把這幾件事寫進 rubric：

• 有沒有清楚列出對照組與變因。
• 有沒有說明這個實驗為什麼能驗證假說。
• 有沒有指出可能失敗的原因。

更狠一點，我會要求模型回答「什麼結果會推翻你的假設」。這題很有效，因為會把只會順著講的模型直接逼出原形。能不能接受反證，通常比會不會講漂亮話更能看出它懂不懂科研。

這不只給研究員看，採購和產品團隊更該看

很多人以為 benchmark 只是模型團隊在玩的東西，我不這麼看。對採購、產品、甚至法務來說，benchmark 其實是在幫你把「好不好用」變成可以對話的標準。尤其生命科學這種高風險場景，不能只靠 demo 氣氛做決定。

LifeSciBench 這類基準最大的價值，就是把評估語言統一起來。沒有這個語言，每個供應商都可以自己定義成功：今天說準確率，明天說流暢度，後天說使用者滿意度，最後就是誰簡報做得好誰贏。這種玩法我看太多了，真的很煩。

我會建議團隊直接把採購問題換成更硬的版本：

• 你們測的是哪一類科研任務？
• 你們怎麼分辨推理和背答案？
• 有沒有失敗案例？

實操上，我會先做一頁自己的評測表，不要一開始就信 vendor 的簡報。把你們真正在意的任務列出來：文獻回顧、靶點比較、protocol 草擬、結果解讀、失敗分析。再把每個任務的最低可接受標準寫清楚。這樣你才知道模型是在幫忙，還是在演。

如果我要把它做成產品，我會先拆成三條線

LifeSciBench 對我來說，不只是 benchmark，還像一張提醒卡：別把 retrieval、reasoning、workflow support 混在一起裝成一件事。很多產品死得很冤，就是因為把這三件事揉成一團，然後說自己「懂研究」。

我如果要做一個生命科學助手，第一件事就是把能力拆開。檢索是檢索，推理是推理，實驗規劃是實驗規劃。這三條線的失敗模式完全不一樣，不能用同一個分數糊弄過去。第二件事是把不確定性攤開來，別假裝模型每次都很有把握。科學工作最怕的就是把模糊答案包裝成定論。

第三件事，我會讓模型「交代它怎麼想」，但不是那種假裝有 chain-of-thought 的表演，而是讓它把依據、假設、限制條件講明白。研究人員要的不是神諭，是可檢查的判斷。只要這件事做不到，產品再順口都沒用。

這也是我覺得 LifeSciBench 很實際的地方。它不是在吹模型有多厲害，而是在提醒你：如果你要進生命科學，就得先證明你能在這種工作裡活下來。

可抄的模板

# LifeSciBench-style 生命科學模型評測模板

## 目標
評估模型能不能支援真實生命科學工作，而不只是回答看起來很聰明的問題。

## 任務類型
1. 文獻理解
   - 精準摘要單篇論文
   - 比較兩篇結論衝突的研究
   - 抽取機制、方法、限制

2. 知識整合
   - 串起多篇來源的證據
   - 區分 evidence 和 speculation
   - 解釋為什麼不同研究會得出不同結果

3. 實驗設計
   - 提出可驗證的實驗
   - 列出對照組、readout、confounders
   - 說明什麼結果會支持或推翻假說

4. 工作流支援
   - 草擬 protocol 大綱
   - 建議 inconclusive result 的下一步
   - 找出實務限制與失敗模式

## 評分規則
每題 1 到 5 分，分別看：
- Accuracy
- Reasoning quality
- Evidence use
- Experimental usefulness
- Uncertainty handling

## 失分紅旗
- 很有自信但沒有證據
- 忽略對照組或 confounders
- 把相關性講成因果
- 沒有處理衝突證據
- 給出漂亮但不能行動的答案

## 題目格式
Task: [任務]
Context: [paper / dataset / lab scenario]
Question: [要模型做什麼]
Constraints: [時間、預算、方法、資料]
Output requirements:
- Clear answer
- Assumptions listed
- Evidence cited
- Limitations stated
- Next step recommended

## 評測流程
1. 跑模型完成所有任務。
2. 找領域專家抽樣評分。
3. 記錄失敗案例。
4. 更新 prompt 和 rubric。
5. 每次模型大改版後重測。

## 採購提問清單
- 你們測過哪些生命科學任務？
- 怎麼區分 reasoning 和 fluency？
- 能不能提供失敗案例？
- 模型怎麼處理互相衝突的證據？
- 它怎麼支援實驗設計？

## 通過標準
模型只有在能做到以下幾件事時才算及格：
- 準確摘要證據
- 整合多來源資訊
- 提出可辯護的實驗
- 說清楚不確定性
- 避免無根據的科學斷言

這段我會真的存進 repo 或內部文件。因為生命科學評測最怕的就是一不小心變成口號，大家都說自己有在看 quality，實際上沒人知道 quality 到底是什麼。

原始來源是 https://zhuanlan.zhihu.com/p/2050933474085885689。我這篇的拆解是基於那篇 Zhihu 整理，再加上我自己對生命科學模型評測的工作流整理；如果你要看原始 benchmark 脈絡，可以再去對照 OpenAI、Hugging Face 和 arXiv 上的相關資料。