打造最好的 agentic 資料分析 harness：由 Claude 驅動，用 Claude Code 打造（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 Omni 是一家做 AI 資料分析的公司，他們的 CTO 在這支影片分享兩件事：工程團隊怎麼靠 Claude Code 加快開發，以及他們的分析 agent Blobby 怎麼一步步變得更會回答問題。Blobby 的核心做法，是在 data warehouse（公司集中存放資料的地方）上面加一層 semantic layer（把資料整理好、翻譯給 AI 看的中間層）。如果你想讓 AI 看懂公司內部的資料，這支影片把「要先告訴 AI 哪些背景」講得很具體。

• 00:21 Omni 是一個 AI 分析平台。講者是 Omni 的 CTO，這場要談他們怎麼用 Claude 開發、用 Claude 做出了什麼，以及 Claude 怎麼驅動這些產品
  ↳ Omni 做的是讓人用提問的方式分析公司資料的工具。講者是公司的技術最高主管（CTO），要分享三件事：團隊怎麼用 Claude 寫程式、做出了什麼產品、產品背後怎麼靠 Claude 運作。
• 00:21 講者帶領 Omni 的工程團隊，大約有 25 位工程師；投影片上是他們 commit 到 main branch 的數量隨時間變化的圖
  ↳ 團隊大約有 25 位工程師。commit 是工程師把改好的程式存進去的一筆紀錄，main branch 是正式版本的主線。所以這張圖看的是團隊產出量怎麼隨時間變化。
• 00:51 講者原本以為當上成長中公司的 CTO 後就得停止寫程式，但有了 Claude，他現在還能繼續寫程式，這是導入後意想不到的好處
  ↳ 公司變大以後，CTO 通常忙著管人、開會，沒時間自己寫程式。有 Claude 幫忙分擔，他還能抽出時間親自動手，這是他原本沒想到的收穫。
• 01:23 2025 年初，公司告訴團隊：工作型態一定會改變，先開始實驗、使用這些工具，找出哪些做法有效。過程斷斷續續、有起有落
  ↳ 2025 年初公司的態度是：AI 一定會改變大家工作的方式，與其等別人給答案，不如先動手試，自己摸出有用的做法。過程並不順，有時候好用、有時候卡住。
• 01:23 搭配 Opus 模型的 Claude Code 推出後，資深工程師開始認為「這是玩真的」，因為它能穩定地提供幫助
  ↳ Claude Code 是讓 Claude 直接在電腦上讀程式、寫程式的工具，Opus 是 Claude 裡能力比較強的模型。兩個搭在一起後表現夠穩定，連原本在觀望的資深工程師也開始認真看待。
• 01:54 大家放完年假、1 月回來時，都已經熟悉 Claude Code、可以直接上手。從那之後 commit 曲線的斜率明顯變陡
  ↳ 年假期間大家各自把工具摸熟，1 月一回來就直接拿來用。從那之後，圖上的 commit 數量成長得明顯更快，代表團隊的產出真的變多了。
• 01:54 開發速度是 Omni 文化的重要部分，公司的核心價值包括「Ship It」和「透明」
  ↳ 「Ship It」的意思是做出來就趕快推出去給人用，不要一直拖；「透明」是把正在做的事公開給大家看。開發要快，是他們很重視的文化。
• 02:25 每週五 Omni 會開全員會議：約 10 分鐘宣布事項和互相感謝，接著 50 分鐘以上的 demo。全程錄影，CEO 會在週六早上剪輯後上傳 YouTube
  ↳ 每週五的全員會議，大部分時間拿來 demo，也就是現場展示新做好的功能。會議全程錄影，CEO 會在週六早上親自剪好、放上 YouTube，公開程度很高。
• 02:55 想知道 Omni 在做什麼，可以到 omni.co 看 demo。這種做法能讓客戶、潛在客戶和社群了解他們的想法與開發方式
  ↳ 把內部的 demo 公開出去，客戶和有興趣的人不用等正式公告，就能直接看到他們在做什麼、怎麼想。這就是「透明」這個價值實際的做法。
• 03:25 運作流程：使用者提問，Claude 把問題轉成 semantic query，再透過 semantic layer 轉成 SQL，最後在資料倉儲上執行
  ↳ 你用白話提問，Claude 先轉成 semantic query（照公司資料定義寫出的查詢），semantic layer 再把它翻成 SQL（資料庫看得懂的查詢語言），最後送到 data warehouse 執行。
• 03:57 Claude 很會回答問題，但要回答你公司的問題，就得告訴它你的業務怎麼運作、你們用的術語，還有資料長什麼樣子
  ↳ Claude 有一般知識，但不了解你的公司。要它答對，得先給它 context，也就是背景說明：你們怎麼做生意、內部的行話、資料長什麼樣子，就像新同事到職要先交接一樣。
• 04:27 這件事其實不容易：例如「上一季」在 Omni 的產品工程部門指日曆季，在業務團隊卻指會計季，這些都要寫進 context 和資料定義裡
  ↳ 同樣說「上一季」，工程部門指的是日曆上的季，業務講的卻是 fiscal quarter，也就是依公司自訂會計年度切出來的季。AI 自己不會知道這種差別，一定要明確寫進定義裡。
• 04:59 Semantic layer 的功能一：整理（curate）資料。實際的資料倉儲可能有數萬到數十萬個資料集，例如 100 張 revenue 表，可以直接標明哪張才是重要的
  ↳ curate 就是挑選、整理。公司的資料倉儲可能有幾萬到幾十萬份資料，光營收表就可能有 100 張，semantic layer 可以直接標出「看這張才對」，免得 AI 抓錯。
• 06:01 功能二：編寫 context。他們學到，context 放在它所描述的定義旁邊，效果會更好
  ↳ 第二個功能是寫 context。他們發現，把說明直接寫在那筆資料的定義旁邊，效果比另外集中寫在一份文件好，因為 AI 查到那筆資料時就會順便看到說明。
• 06:01 類比 Claude Code 的 Claude.md：context 放得越靠近它適用的程式碼，結果越好。semantic layer 也是把 context 放在對應欄位定義旁邊，而不是另外放在別的檔案
  ↳ Claude.md 是放在專案裡、寫給 Claude Code 看的說明檔，放得越靠近對應的程式碼效果越好。semantic layer 也是一樣：每個欄位的說明，直接寫在該欄位的定義旁邊。
• 06:33 功能三：權限。確保使用者看得到該看的資料、看不到不該看的資料
  ↳ 第三個功能是權限控管，確保每個人只看得到自己該看的資料。AI 幫忙查資料時也要守同一套規矩，不會因為是 AI 在查，就把不該給的資料拿出來。
• 06:33 實際組織裡的資料不斷在變，所以應用程式提供回饋迴圈：把後續的提問回饋到定義和 context 裡，形成持續學習的循環
  ↳ 公司的資料和用語一直在變，一次寫好的定義很快就會過時。feedback loop（回饋循環）就是把使用者後來的追問和修正補回定義和 context 裡，讓系統越用越準。
• 07:05 他們的 agent 叫做 Blobby，大約 18 個月前開始開發，一路學到很多
  ↳ agent 是能自己規劃步驟、連續做好幾件事來完成任務的 AI，不是只回一句話。他們的 agent 叫 Blobby，大約 18 個月前開始開發，一路學到很多。
• 08:40 Demo 步驟一：Blobby 知道「PRs」指的是 GitHub pull requests，接著到 semantic model 裡找出對應的資料
  ↳ 使用者問「PRs」，Blobby 會先理解這是 GitHub 上的 pull request（工程師送出程式修改、請同事審核的申請），再到 semantic model（整理好的資料定義）裡找出對應的資料。
• 08:40 步驟二：查看資料集的實際值，決定篩選條件（指定的 repository），並用 fuzzy matching 處理使用者打錯字的情況
  ↳ 接著它會看資料裡實際存了哪些值，確定要篩選哪一個 repository（存放程式的專案庫）。就算使用者打錯字，fuzzy matching（模糊比對）也會找出最接近的正確名稱。
• 09:10 步驟三：產生 query、在資料倉儲上執行、取得結果、產生視覺化圖表，最後附上一段摘要
  ↳ 然後它寫出 query（查詢指令），拿到資料倉儲執行、取回結果，自動畫成圖表，最後再附一段文字摘要重點。使用者從提問到看懂答案，完全不用碰技術步驟。
• 09:10 第一版 Blobby 基本上是「一問一答」，他們很快發現必須提供更多 metadata，也就是資料該怎麼用、通常怎麼被使用
  ↳ 第一版只會一問一答：問一句、查一次、回一次。他們很快發現這樣不夠，還要多給 metadata，也就是描述資料的資料，例如這個欄位該怎麼用、大家平常怎麼用它。
• 09:40 定義裡原本就有 label 和 description 欄位，後來新增專門寫給 LLM 看的「AI context」，讓資料團隊和管理員能引導 LLM 往正確方向走
  ↳ label 是欄位的顯示名稱，description 是寫給人看的說明。他們另外加了 AI context，專門寫給 LLM（Claude 這類大型語言模型）看，讓資料管理者可以直接教 AI 正確的用法。
• 10:11 新增 sample queries：提供典型用例，以及回答某類問題時應該執行的 query，幫助模型有所依據
  ↳ sample queries 就是範例題加上標準解法：遇到哪一類問題，應該跑哪一段查詢。AI 有範本可以參考，不必每次都從頭猜，答案也會比較穩定。
• 10:11 新增 values：讓 LLM 看到欄位的部分實際值，例如 region 欄位有 EMEA、NAM、APAC，它就能推斷出這些是地區縮寫
  ↳ 只看到欄位名稱「region」，AI 不知道裡面的資料是怎麼寫的。讓它看幾個實際值，像 EMEA、NAM、APAC，它就能判斷這些是地區的英文縮寫。
• 10:41 LLM 知道欄位值是縮寫後，使用者問「United States」時，它就知道要填入 U.S.。這些做法都提升了問答品質
  ↳ 知道是縮寫以後，使用者問「United States」，AI 會自動換成資料裡的「U.S.」去查，不會拿全名去找結果找不到。這些小補強加起來，讓回答品質明顯提升。
• 11:11 不過當時 Blobby 還不算 agent。下一個大躍進是加上 agentic loop：他們自己打造了 agentic harness，裡面有 tasks 等概念，是一項很大的工程
  ↳ 當時 Blobby 還只會一問一答。agentic loop 讓 AI 反覆「做、看結果、再調整」；撐起這個循環的 harness（底層框架），包括 tasks 等設計，是他們自己打造的，工程量很大。
• 11:41 最大的收穫：agentic loop 很擅長從錯誤中恢復。做法是 A）告訴 Blobby 如何從錯誤恢復，並給它執行的預算；B）提供描述清楚的錯誤訊息，說明發生什麼事、可以怎麼修
  ↳ 最大的收穫是 agent 出錯時能自己修正再試。關鍵有兩個：一是教它出錯時怎麼補救，並給它一定的執行額度；二是錯誤訊息要寫清楚哪裡出錯、可以怎麼修。
• 11:41 光是這樣，品質分數就大幅提升，許多較難的 evals 成績也明顯變好
  ↳ evals 是一組固定的考題，用來衡量 AI 答得好不好。光是做了錯誤恢復這兩項改進，整體品質分數就大幅上升，比較難的考題成績也明顯進步。
• 12:11 一問一答階段用的是 Haiku 模型。它很好，但不是為較複雜的 agentic 對話設計的，所以改用 Sonnet
  ↳ Claude 有不同等級的模型：Haiku 比較輕快，Sonnet 能力比較強。一問一答的階段用 Haiku 就夠了，但它不是為多步驟的 agent 對話設計的，所以改用 Sonnet。
• 12:11 改用 Sonnet 後 token 用量上升，原因一：對話更長、更複雜，本來就會用掉更多 token，這是刻意的設計
  ↳ token 是 AI 計算讀寫文字量的單位，通常也是計費的依據。改用 Sonnet 後 token 用量上升，第一個原因是對話變長、步驟變多，這是他們刻意接受的結果。
• 12:41 原因二：這是很大的突破。客戶反映，自己可能答不出來、或要花好幾個小時的問題，Blobby 兩分鐘就答對了，Blobby 的使用量從此大幅成長
  ↳ 第二個原因是它真的好用：客戶說，自己答不出來、或要花好幾個小時才查得到的問題，Blobby 兩分鐘就答對了。Blobby 的使用量從此大幅成長。
• 12:41 CEO 是他們最大聲、最挑剔的使用者，會直接要求「它這題答錯了，去修好」；團隊回應 CEO Colin：LLM 本來就有點難以預測（本段在此結束）
  ↳ CEO Colin 是最常用、也最挑剔的使用者，一看到答錯就直接要團隊去修。團隊的回應是：LLM 本來就有點難預測，沒辦法保證每一題都答對。

Omni 的 Blobby 在「一問一答」階段原本使用哪個模型，後來因為 agentic 對話更複雜而改用 Sonnet？