用自訂 DSL 讓 agentic workflow 值得信任、可以驗證（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這段用 Elicit（一個 AI 研究助理工具）的實際操作，示範怎麼讓 AI 的每一步都攤開給人看、也能檢查，而且確實照著計畫做。後半段講者分享自己做這套系統的心得。值得看的原因是，它回答了一個大家都會遇到的問題：AI 給你一份很像樣的答案，你憑什麼相信它？

• 14:50 在嚴謹和速度的取捨上，Elicit 很明確偏向嚴謹。簡單問題也會很快回答，但講者說那不是他們跟別人不一樣的地方
  ↳ Elicit 寧可慢一點，也要把事情做對。簡單的問題它也能馬上回答，但那不是它的賣點。它想贏的是查證扎實、經得起檢查的答案。
• 14:50 elicit.com 首頁有幾種範本可以直接開始，例如建立表格、投影片、起草報告
  ↳ 打開 elicit.com 首頁就有現成範本，像是做表格、做投影片、起草報告，不用從一片空白開始想要怎麼下指令。
• 15:21 Demo 用的是一份事先存好的 research landscape session，前後大約花了幾個小時，因為中間講者一直往上加新的分析層；講者也說不一定要花這麼久
  ↳ Demo 開的是一份事先存好的 research landscape（某個領域的全貌調查）。會花好幾個小時，是因為講者一路往上加分析，不是系統本來就這麼慢。
• 15:52 一開始的問題是：找出投資生物學 foundation model 的公司和機構
  ↳ 起點很單純：想知道哪些公司和機構在投入生物學的 foundation model。foundation model 指的是用大量資料訓練、之後能拿去做很多不同任務的大型基礎模型。
• 15:52 系統先反問使用者要把範圍縮小到哪裡，例如要廣泛的全貌、特定的 foundation model，還是要偏重學術機構或公司；講者選了廣泛的全貌
  ↳ 系統沒有急著開始搜，而是先反問要查多廣：看全貌、盯某個特定模型，還是偏重學界或業界。就像助理先確認需求，免得做半天方向錯了。講者選了看全貌。
• 16:22 之後每個步驟都由 DSL（字幕拼作 Ash PL／HPL）驅動：搜尋學術論文、做網路搜尋、盡量抓論文全文、再做 screening（篩選）
  ↳ DSL 是為特定用途量身打造的小型程式語言。這裡每一步都寫成 DSL 來跑：查論文、上網搜尋、抓全文，再做 screening，也就是篩掉不相關的結果。
• 16:54 這份 DSL 不只是用來描述計畫，它本身就是可以執行的計畫。所以他們能確定系統真的照著寫好的計畫做
  ↳ 關鍵在於「計畫本身就是程式」：寫下來的東西就是實際執行的東西，不是事後補寫的說明。所以系統只能照計畫做，不會偷偷走別條路。
• 17:24 往後的分析找出了具體機構，例如 Howard Hughes Medical Institute、Stanford University，中間又做了更多搜尋和篩選，挖得很深
  ↳ 分析一層一層往下挖，找出像 Howard Hughes Medical Institute、Stanford 這些具體機構，中間又追加了好幾輪搜尋和篩選。
• 17:56 最後產出一張表格，Elicit 叫它 artifact。每一列是一個投入生物學 foundation model 的組織，例如 GDM、Meta、Microsoft Research
  ↳ 最後產出一張表，Elicit 叫它 artifact（產出物）。每一列是一個投入生物學 foundation model 的組織，例如 GDM（Google DeepMind）、Meta、Microsoft Research。
• 18:26 表格還抽出了每個組織的屬性：做過哪些 foundation model、關注哪些 modality、有哪些重要合作
  ↳ 每個組織還整理出幾個欄位：做過哪些模型、處理哪種 modality（資料類型，例如 DNA 序列、蛋白質結構），以及跟誰有重要合作。
• 18:26 每個 artifact 都能打開當初產生它的 DSL 程式碼，看到的就是實際跑過的那份
  ↳ 每張表都能點開，看當初產生它的 DSL 程式碼，而且是真的跑過的那一份。等於每份成果都附上一份完整的施工紀錄。
• 18:56 程式碼裡能看到網路搜尋、學術論文搜尋，以及把兩邊結果 join 起來的地方
  ↳ 程式碼裡看得到哪裡上網搜、哪裡查論文，以及哪裡做了 join。join 就是依共同欄位（例如組織名稱）把兩份清單對起來合併。
• 19:26 講者承認直接讀 DSL 不太有趣，大多數使用者也不會去讀。做這套 DSL 的主要目的是確認系統有照著擬好的指令執行
  ↳ 講者老實說，一般人不會去讀這些程式碼。DSL 主要不是寫給人看的，是讓團隊確定系統真的照擬好的計畫在做，沒有自己亂改步驟。
• 19:26 計畫寫成這種好讀的格式後，其他 agent 也能檢查它，指出漏掉的關鍵搜尋，或沒顧到的使用者需求
  ↳ 計畫寫得清楚好讀，就能交給另一個 AI agent（會自己分步驟做事的 AI）來審，挑出漏掉的關鍵搜尋或沒顧到的需求，有點像請同事幫忙校稿。
• 19:56 對使用者比較順手的是圖形化的流程圖。它直接從 DSL 產生，跟實際執行的計畫是同一份，不是另外畫的漂亮示意圖
  ↳ 對一般使用者來說，流程圖比程式碼好懂。重點是這張圖直接從 DSL 產生，跟實際執行的是同一份，不是另外畫、可能跟實際對不上的美化示意圖。
• 20:29 這個例子的流程大致是線性的：搜尋 → enrichment（抓論文全文等）→ extracting（抽取）→ curating（篩選）→ 再搜尋
  ↳ 這次的流程大致是一直線：搜尋 → enrichment（補資料，例如抓全文）→ extracting（抽出需要的資訊）→ curating（篩選）→ 再搜尋一輪。
• 20:29 講者會用流程圖判斷自己認不認同系統走的流程，哪裡怪怪的很快就看得出來
  ↳ 講者用流程圖快速檢查：這樣查我同不同意？哪一步順序怪、少了什麼，一眼就看得出來，不用一行一行讀程式。
• 20:59 講者接著往上加分析：比較各組織的開源和閉源策略、商業化策略與 GTM 做法、整理政府機構和其他監管機構
  ↳ 接著繼續往上疊分析：比較各組織走開源還是閉源、怎麼賺錢、GTM（go-to-market，產品怎麼推上市場、賣給誰）怎麼做，再整理政府和監管機構。
• 21:30 最後講者用自然語言要求把「組織」表和「監管機構」表 join 起來，看各 lab 怎麼跟監管機構互動
  ↳ 講者沒寫程式，只用平常說話的方式，要求把「組織」表和「監管機構」表 join 起來，想看各家研究單位怎麼跟監管單位往來。
• 22:01 join 後的表格列出例子，像是 Anthropic 跟 US AI Safety Institute、英國相關機構的互動
  ↳ 合併後的表列出了具體例子，例如 Anthropic 跟美國 AI Safety Institute、英國相關機構之間的互動。
• 22:33 這張新表的 DSL 開頭跟第一張表一模一樣，網路查詢和論文查詢都相同，只是程式變長了：從大約 100～150 行變成 1,000 行左右
  ↳ 新表的程式開頭跟第一張一模一樣，代表它是接在原本的基礎上往下做，不是從頭重來。只是程式從大約 100～150 行長到約 1,000 行。
• 23:35 產生最後那張表時，整份程式會從頭重新 interpret 一次，但因為有 cache，前面做過的查詢會直接拿到記住的結果，所以很快
  ↳ 每次產出都會把整份程式從頭 interpret（逐步解讀並執行）一次。但因為有 cache（把做過的結果記起來），查過的東西直接拿舊結果，所以不會慢。
• 24:07 每次都跑完整份程式，比較容易有信心，也能對一致性和正確性做統計上的保證。只跑零碎片段的話，就可能出現 drift
  ↳ 每次都完整跑一遍，結果才會前後一致，也能做統計上的品質保證。如果只挑片段來跑，結果可能慢慢對不上，這就叫 drift（漂移）。
• 24:38 講者不認為每個人都該用 DSL。DSL 不是最容易做的東西，要等產品和組織的需求真的指向它才值得
  ↳ 講者沒有要大家都用 DSL。它做起來不簡單，要等你的產品和團隊真的需要這種程度的掌控，才值得投入。
• 24:38 Elicit 選 DSL，是因為產品核心是高品質、可靠、穩健和資料來源可追溯（data provenance）
  ↳ Elicit 選 DSL，是因為產品核心就是品質、可靠、穩定，以及 data provenance（資料來源可追溯：每一筆資料從哪裡來都查得到）。
• 25:08 要做 DSL 系統的注意事項，第一點最明顯：你得有一套 DSL
  ↳ 接下來列出做 DSL 系統的注意事項。第一點很直白：你得先有一套 DSL，也就是先定好 AI 能用哪些指令、要怎麼寫。
• 25:08 Agent 好不好用（agent ergonomic）：DSL 最好以訓練資料裡範例很多的既有語言為基礎，模型就不用重新學語法，只要知道能用其中一個子集
  ↳ agent ergonomic 指的是對 AI 好不好上手。DSL 最好建立在 AI 早就看過大量範例的現成語言上，只限定用其中一部分，AI 就不必從頭學新語法。
• 25:39 DSL 本身花的工夫少得驚人，大部分工作是把它變成能運作系統的傳統軟體工程
  ↳ 意外的是，設計 DSL 本身不太費工。真正花力氣的是周邊的一般軟體工程，要把它接成一個穩定、每天都能運作的系統。
• 26:09 Wrapper：讓系統能在不同 harness 和模型之間切換
  ↳ wrapper 是包在外面的一層程式。它讓系統能在不同的 harness（驅動 AI 模型執行任務的底層框架）和不同模型之間切換，不會被單一工具綁死。
• 26:09 Interrupt handling：等結果時，使用者可以在聊天裡補充內容，要能順利傳回 curator，讓它不用停下整個流程就改計畫。講者說沒有 harness 原生支援這件事
  ↳ interrupt handling（插話處理）：系統在跑的時候，使用者在聊天裡補一句，要能送到 curator（負責寫計畫的模型）讓它改計畫，不用整個停下來。現成工具都沒有內建這個功能。
• 26:09 Session 要能在之後重新 rehydrate（恢復），這也不是原生功能，得自己做一整套
  ↳ rehydrate（恢復）：過幾天再打開舊的 session（一次工作紀錄），要能接著做，像沒離開過一樣。這也沒有現成功能，得自己做一整套。
• 26:39 Credential isolation：由前面提到的 wrapper 負責
  ↳ credential isolation（憑證隔離）：把帳號密碼、金鑰這類存取權限隔開來管理，避免外洩或被亂用。這件事交給前面提到的 wrapper 負責。
• 26:39 處理模型輸出的訊息要做的事多到很煩，得確保訊息不會就這樣掉進 standard out 不見
  ↳ 模型吐出來的每則訊息都要好好接住、處理，不能只印在 standard out（程式預設的輸出畫面）上就消失、沒被記錄。很瑣碎，但省不得。
• 26:39 第 7 點：他們用 event sourcing，很滿意這個模式，但要做起來不輕鬆
  ↳ 第 7 點是 event sourcing：不只存最新狀態，而是把每個發生過的事件照順序記下來，需要時可以重播還原。Elicit 很滿意，但做起來不輕鬆。
• 27:09 講者的建議：第 1 點一定要做，第 2 點推薦做，第 3～6 點大多數人可能都需要，第 7 點總得有個做法
  ↳ 講者的建議：第 1 點（要有 DSL）一定要做，第 2 點（對 AI 好上手）推薦做，第 3～6 點多數人大概都需要。第 7 點不一定用同樣方法，但總得有一套做法。
• 27:09 第 8 點是 eval：Elicit 有專門的 eval 團隊。系統會即時寫程式再執行，eval 非常困難，講者強烈建議做 DSL 系統的人也要投資在這裡
  ↳ 第 8 點是 eval（評估，也就是有系統地測 AI 做得好不好）。系統是邊跑邊自己寫程式，每次都可能不一樣，所以非常難測。Elicit 有專職團隊在做，講者強烈建議投資在這裡。
• 27:41 回到開頭的問題：兩個系統產出一模一樣的結果，你該相信它嗎？
  ↳ 回到開場的問題：如果兩個系統給你一模一樣的表，你該相信它嗎？也就是說，光看結果就能決定要不要信嗎？
• 28:11 講者說，至少從表面看，Opus 這類最先進的模型做出類似的表格並不奇怪
  ↳ 講者承認，像 Opus（Anthropic 的頂級模型）這類最新模型，至少從表面看，做出很像的表格並不奇怪。
• 28:41 差別在於 Elicit 走過一套嚴謹、費工的流程，並透過 DSL 和流程圖讓使用者容易看到。講者從與使用者的對話得知，他們看待這兩張表的方式很不一樣
  ↳ 差別在過程：Elicit 走了一套嚴謹又費工的步驟，還用 DSL 和流程圖攤開給你看。講者從跟使用者聊天中發現，大家看待這兩張表的方式很不一樣。
• 29:12 結論：重點不是叫大家去用 DSL，而是要很在乎產出的機制，因為機制很重要
  ↳ 結論不是叫大家都去做 DSL，而是別只看答案漂不漂亮，要在乎答案是怎麼產生的。過程看得見、查得到，結果才值得信。

在 Demo 裡，講者要求把組織表和監管機構表 join 起來後，那張表背後的 DSL 程式有什麼變化？