讓全公司自助問數據的 Studio

概要

• 傳統流程的痛點非技術同事有問題，得找懂 SQL 的人，來回解釋脈絡、補資料；dashboard 又太固定，換個問題就要重做。
• Studio 的運作從 Slack bot 或內部 dashboard 提問，背後是一支 API 加上用 Opus 的 agent，經 proxy 連到 Snowflake、Linear、Notion，並有一層規則告訴它怎麼查這些資料。
• 答案變成 widget問完之後可以請 Studio 做成可重複使用的工具。widget 是 sandbox 裡的程式碼，含 UI、API 與查詢；重新整理時直接重跑查詢，LLM 不參與。
• 支援團隊自助Garrett 說支援團隊常在 Slack 裡用，一次性問題自己查，常被問到的再做成 widget 分享，不需要平台團隊或資料團隊一直維護 dashboard。
• 可靠度靠三件事sequencing（先做 pre-flight 檢查、用到工具才注入脈絡）、layering（prompt 分層，且要求模型查文件而非靠舊知識）、validation（寫進 widget 前先實際跑查詢）。
• Q&A 的取捨沒有用 RAG，只在工具上加脈絡；查詢正確性靠「信任但驗證」與寫進脈絡的常見過濾條件；權限目前以個人登入為主，正改用自家 Pipes；他們願意為 Opus 付成本。

原話

• “we don't need to have some sort of platform team or data team building these dashboards that are gonna be used and need to be constantly modified.”

  我們不需要專門的平台團隊或資料團隊，去做那些得一直修改的 dashboard

  ▶ 09:28

• “Many times, it can have a valid SQL query, but that returns zero data.”

  很多時候 SQL 本身合法，卻查不到任何資料

  ▶ 12:05

• “You don't need to rag all this stuff. There's no rag database for us in all of this.”

  不需要把這些全部做成 RAG，我們這整套沒有 RAG 資料庫

  ▶ 14:03

• “the actual final product is very reliable in that regard”

  最後產出的東西在這方面非常可靠

  ▶ 16:32

• “Opus outperforms better than other models so much that trading the cost off would trade off quality in a way that we wouldn't deem acceptable”

  Opus 比其他模型好太多，拿成本換掉的話，品質的損失我們無法接受

  ▶ 18:30

延伸

• 工具的使用脈絡在呼叫那一刻才注入。Snowflake 那份很長，幾乎把內部資料庫的 schema 都寫進去；Garrett 說預先載入所有工具的脈絡會塞爆 context window。
• 欄位名稱夠自我描述時，LLM 讀 schema 就很準；他們補的是像 Radar 的 attempts 與 detections 該怎麼 join 這類知識。
• 權限層還在建構中：目標是一人設定連線，再依 Studio 內的角色決定預設的唯讀或編輯權限。