前一篇講了為什麼 trace 是 AI agent 的 source of truth，但知道 trace 重要是一回事，怎麼從每天幾百萬筆 trace 中提取 insight 是另一回事。

LangChain 的 LangSmith Insights Agent 是目前我看到在這個問題上做得比較完整的產品。最近剛好看到三個不同視角的資料: 一份詳細的逆向工程分析拆解了完整的 6 階段 pipeline，官方文件和產品 blog 描述了功能和架構，再加上 LangChain 工程師 Anika Somaia 在 Jason Liu 的 Maven 課程中分享了從研究論文到生產部署的完整開發歷程。

把這三個角度拼起來，可以看到一個蠻完整的故事: 不只是「這個系統怎麼運作」，還有「為什麼做成這樣」以及「過程中踩了什麼坑」。

起點: Anthropic 的 Clio 論文

Insights Agent 的靈感來自 Anthropic 的 Clio（Claude Insights and Observations）論文。Clio 做的事情是: AI 助手在真實世界中到底被怎麼使用的？人們在問什麼？哪些地方做得好？哪些不好？

LangChain 團隊覺得這個想法很有意思，想把同樣的方法應用到「agent 在生產環境中被怎麼使用」這個問題上。

但最後做出來的東西跟 Clio 長得非常不一樣。Anika 在演講中提到一個關鍵差異:

Clio 主要是按對話主題做 clustering — 人們在聊什麼。但當我們把這個概念放到生產環境給客戶用時，發現他們更想知道的是: 我的 agent 在哪裡出錯了？ 對研究有用的東西，跟對生產中的人有用的東西，是不一樣的。

所以他們從一個「研究風格的 topic clustering 工具」出發，最後做成了一個 debugging 工具。這個轉變不是計畫好的，而是被真實使用者的需求推動的。

核心概念: 用 LLM 來分析 LLM 的 trace

傳統的 BI/analytics 做法是: 你先定義維度和指標，寫好 query，然後跑報表。問題是你必須事先知道要找什麼。

Insights Agent 的做法不一樣: 你用自然語言問問題，系統自動把問題翻譯成整套分析 pipeline — 從摘要生成、到 clustering、到標籤生成。這是一個「用 LLM 驅動的分析工具」，而不只是「用來看 LLM trace 的 dashboard」。

  傳統 BI 做法 Insights Agent 做法
流程 你定義特徵 → 演算法分群 → 你解讀 你問問題 → LLM 定義特徵 → LLM 分群 → LLM 解讀
門檻 需要分析專業 自然語言，PM 也能用
分群維度 固定的 動態，根據問題調整
標籤品質 “Cluster 0”, “Cluster 1” “Product Orientation”, “RAG Retrieval Errors”

完整 Pipeline 拆解

根據逆向工程分析，整個系統分成 6 個階段，跑完大概 15-30 分鐘，處理上限 1,000 筆 trace，成本約 $1-2（OpenAI）或 $3-4（Anthropic）:

Phase 0: 自然語言 → 分析規格

用戶回答三個問題:

  1. 「你的 agent 做什麼?」（domain context）
  2. 「你想了解什麼?」（分析焦點）
  3. 「trace 的結構長什麼樣?」（資料格式）

系統用 LLM 把這三個回答翻譯成結構化的分析規格（JSON），包含: 分析模式（usage patterns vs failure modes）、要提取的特徵、summary prompt 模板、特徵權重、sampling 策略等。

這是整個系統最「agentic」的部分 — 一個 LLM call 就把使用者的模糊意圖轉換成精確的分析 pipeline 設定。輸出的 JSON 結構大概長這樣:

{
  "analysis_mode": "usage_patterns",
  "clustering_focus": "question_topics",
  "extract_features": ["product_mentions", "feature_references", "question_intent_type"],
  "attributes": [
    {"name": "user_satisfied", "type": "boolean", "filter_by": false}
  ],
  "summary_prompt": "Summarize this conversation:  ",
  "feature_weights": {"semantic": 0.75, "behavioral": 0.25},
  "sample_strategy": {
    "target_size": 1000,
    "stratify_by": ["thread_length", "recency"],
    "oversample_long_threads": true
  }
}

除了 Auto 模式（回答三個問題），還有兩種配置方式:

  • Prebuilt Config: 直接載入預設的「Usage Patterns」或「Error Analysis」設定，可以直接跑或微調
  • From Scratch: 手動設定所有細節 — 取樣大小（最多 1,000）、時間範圍、categories（自動生成或預先定義 top-level）、summary prompt（含 mustache 模板）、自定義 attributes、model provider（OpenAI 或 Anthropic）

有一個重要的配置演化故事: 早期版本要求使用者填一大堆東西 — 自己定義 cluster 數量、手動寫 summary prompt、指定每層要幾個 category。團隊以為使用者會想要這種細粒度控制，但實際反饋是: 這太複雜了，我根本不知道我想要幾個 category，那取決於我的資料啊。

所以他們做了大幅簡化。從一堆 config 欄位，變成現在的三個簡單問題 + 兩個預設模式（error analysis 和 usage patterns）。Anika 的反思很直白:

如果需要一堆配置才能得到好結果，我們認為那就是「不 work」。

這對 agent 產品設計是一個很重要的教訓 — configuration 很容易變成 crutch（拐杖），用來掩蓋核心演算法不夠 robust 的問題。

使用前提: Thread 結構

在跑 Insights Agent 之前，你的 trace 需要滿足一些結構要求:

  • Trace 必須組織成 threads（多輪對話）
  • 每筆 trace 的 top-level input/output 必須包含 messages list（支援 LangChain、OpenAI Chat Completions、Anthropic Messages 格式）
  • 需要設定 idle time（定義一段對話什麼時候算「結束」）— 這在首次配置 multi-turn eval 時設定
  • 權限: 需要 Create rules 和 View tracing projects
  • 需要設定 OpenAI 或 Anthropic 的 API key 作為 workspace secrets

Phase 1: 智慧取樣

Production agent 可能每天產生幾百萬筆 trace，全部處理不現實。系統做 stratified sampling，上限 1,000 筆:

  • 按時間分層（近期的更相關）
  • 按對話長度分層（多輪對話通常有更豐富的信號）
  • 長對話會被 oversample（因為包含更多資訊）
  • 保持 reproducible seed 方便 debug

1,000 筆聽起來不多，但根據中央極限定理，500-1,000 個樣本已經足夠做 pattern discovery。這也是一個很務實的 trade-off: runtime 可控（不管你有多少 trace，都是 30 分鐘內跑完）、成本可控（$1-4 per report）。

Phase 2: 針對性摘要 + 過濾

這是最花時間和成本的階段。每筆 trace 可能非常巨大，甚至單一 trace 就可能超過模型的 context window。所以不是把 trace 直接丟給後面的 pipeline，而是先做兩件事:

第一步: 針對性摘要

用 summary prompt 對每筆 trace 做摘要。關鍵是這個摘要是針對使用者問題的 — 如果你在分析 error，摘要會聚焦在 error；如果分析 usage pattern，就聚焦在 usage。這讓摘要變成「針對你分析目標的短文」，而不是通用的對話摘要。

Summary prompt 使用 mustache 語法（例如 、、``）指定要包含 trace 的哪些部分，預設聚焦在最後一個 run。此外還有 message view 設定，控制要看對話的哪些部分:

  • all_messages: 完整對話
  • human_ai_pairs: 只看人類和 AI 的對話配對
  • first_last: 只看第一輪和最後一輪（大幅降低 token 成本）

這很重要，因為每個 agent 的 trace 結構不同，讓使用者控制「哪些部分送進去做摘要」可以大幅提升品質、降低成本。

逆向工程分析還發現，系統同時做兩種特徵提取:

語意特徵（LLM 驅動）: 用戶意圖、討論主題、對話結果、自定義 attributes（支援三種型別: categorical、numerical、boolean）

行為特徵（規則驅動）: 對話輪次、tool call 數量、重複序列偵測、retry rate、error count、延遲、token 用量，甚至包括挫折感偵測（用 regex 抓 “not working”、”frustrating” 等關鍵字）

第二步: 過濾

這是 Clio 論文沒有的步驟，是根據生產需求加上的。原因很實際: 真實資料非常 noisy。Anika 舉了一個很好的例子:

我們有個 Chat LangChain 讓人問 LangChain 文件的問題，但有些人把它當成免費 ChatGPT 用，會問 IPL（印度板球聯賽）的比分。這些 trace 顯然不會告訴我們任何關於「人們怎麼用 LangChain」的事。

如果某個 boolean attribute 設了 filter_by: true（例如 has_error: boolean, filter_by: true），系統會在這個階段把不符合條件的 trace 排除。這確保後面的 clustering 只處理你真正關心的資料。

Phase 3: LLM 驅動的分類（不是 Embeddings！）

這是跟原始 Clio 論文最大的技術分歧。

Clio 的做法: embed 所有 summaries → K-means clustering

Insights Agent 最終的做法: LLM 直接生成 categories

為什麼放棄 embeddings？Anika 的解釋非常具體:

很多 agent 的 trace 是非常 domain-specific 的。很多微妙不同的東西在 embedding 空間中非常相似。例如 LangGraph 和 LangSmith，雖然概念上完全不同，但 embedding 非常接近。我們的確得到了「正確」的 cluster，但它們不 有用 — 因為它們把一個人類不會放在一起的東西放在一起了。

這是一個很重要的洞察: embedding similarity ≠ useful similarity。「I love coffee」和「I hate coffee」的 embedding 很接近（都在談 coffee），但語意完全相反。在 agent trace 的場景中，LangGraph 的問題和 LangSmith 的問題 embedding 相近，但對客服團隊來說顯然不該放在同一類。

所以他們改用 LLM 來做分類。特徵權重會根據分析問題動態調整:

  • 問「用戶怎麼使用我的 agent」→ 語意權重 0.7，行為權重 0.3
  • 問「agent 在哪裡出錯」→ 語意權重 0.3，行為權重 0.7

Clustering 切成兩層:

  • Top-level categories: 可以自動生成，也可以預先定義
  • Subcategories: 永遠是自動生成的

為什麼 top-level 可以預先定義但 subcategories 不行？因為你可能知道大方向（「我想看 error types」），但不知道細節。讓系統自動發現 subcategories 是這個工具最有價值的部分 — 它會告訴你「你不知道自己不知道的東西」。

逆向工程分析中有一個很好的例子說明兩層 hierarchy 的價值:

  • Top-level: Information Sourcing（operational mode）
    • Subcategory: RAG Retrieval → 失敗模式是「抓到不相關的 chunks」
    • Subcategory: Web Scraping → 失敗模式是「timeout errors」

同樣都是「資訊來源」，但 RAG 和 Web Scraping 的 failure mode 完全不同。這讓你可以修一整類問題，而不只是修單一 bug。

Trade-off 當然存在: embeddings 可以便宜地處理更多 trace，LLM 分類在準確性和可解釋性上更好但成本更高。團隊做了一個假設: 使用者更在意準確的 broad stroke categories，而不是能 cluster 更多的資料量。

Phase 4: LLM-as-Judge 標籤生成

對每個 cluster，取 5-10 個代表性 trace，丟給 LLM 生成:

  • 類別名稱（2-4 個字，例如 “Product Orientation”）
  • 類別描述（2-3 句話解釋這些對話的共同點）
  • 類別類型（usage pattern / error mode / user intent）

subcategory 也是同樣做法，但會給 LLM 上下文說「這是 X 類別下的子集」，讓它生成更具體的區分。

Phase 5: Metrics 聚合

對每個 category 和 subcategory 計算:

  • 佔比（% of total traces）
  • 平均延遲、P95 延遲
  • Token 用量、成本
  • Error rate
  • Feedback scores
  • 用戶定義的 attribute 聚合值

Phase 6: 報告生成

產出多層級的互動式報告:

📊 Insights Report: "Question Topics"
│
├─ 📁 Product Orientation (35%)
│   ├─ LangChain vs LangGraph Clarification
│   ├─ Platform Feature Discovery
│   └─ General Product Capabilities
│
├─ 📁 Agent Orchestration (28%)
│   ├─ Tool Selection and Sequencing
│   ├─ Memory Management Questions
│   └─ Multi-step Planning Patterns
│
├─ 📁 Retrieval (22%)
│   ├─ Vector Store Questions
│   ├─ General Retrieval Design
│   └─ Document Loading Strategies
│
└─ 📁 ...

每個 category 都可以: 展開看 subcategories → 點進去看 trace table → 選擇 trace 後做 bulk actions:

  • 加入 annotation queue（給人工 review）
  • 加入 dataset（做 offline evaluation）
  • 建立 dashboard monitor（持續監控）
  • 配置新的 multi-turn eval（自動打分）

報告會被 cache 30 天，配置也會存下來方便重跑。報告頂端有 executive summary，直接告訴你「42% 的錯誤是這類、30% 的人問的是那類」，並且 highlight 最值得你看的 trace（帶有可點擊的 reference 連結）。

怎麼用 Eval 迭代一個 Agent: 最值得學的部分

老實說，演講中關於 eval 的部分比 pipeline 架構本身更有學習價值。因為 pipeline 是特定產品的實作，但 eval 方法論是通用的。

挑戰: 「有用」比「正確」難定義得多

傳統 eval 通常關注 correctness — 答案對不對？但對 clustering 來說，「正確的 cluster」和「有用的 cluster」是兩回事。

Anika 舉的例子: 如果把 Chat LangChain 的對話按難度分成「初階問題」、「中階問題」、「進階問題」，這些 cluster 技術上完全正確。但這對任何人都沒有用 — 你不會根據這個去改善你的 chatbot。相比之下，「Core Implementation」、「Architecture Questions」、「Deployment Issues」這種分法才是 actionable 的。

所以他們花了大量時間在 eval 開始之前，先搞清楚「什麼叫有用」。這個過程本身就很有挑戰: 怎麼把「看 vibes 覺得好」翻譯成可量化的 eval 指標？

三個具體的 Eval 指標

1. Vagueness Score（模糊度）

衡量 category 名稱相對於使用者目標是否足夠具體。不是絕對的「這個名字模糊嗎」，而是「給定使用者想知道的事（summary prompt），這些 category 名稱有沒有幫他回答問題」。例如使用者問「users 需要什麼幫助」，得到「Beginner Questions」就太模糊了 — 它正確但不 informative。他們一開始的 vagueness score 很高，經過多次迭代才降下來。

2. Pairwise Consistency（成對一致性）

如果 category 是準確的，那任意兩筆 trace 應該「總是在同一個 category」或「總是在不同 category」。如果跑兩次結果不一樣（這次放一起、下次分開），那就代表分類不穩定。你要這個數字越低越好。

3. Reverse Engineering User Goal（逆向還原用戶目標）

這個最有意思: 把用戶的原始問題藏起來，只給 LLM 看最終的 cluster 結果，問它「你覺得用戶原本想知道什麼？」。如果 LLM 能準確重建出用戶的原始 summary prompt，代表最終結果跟用戶意圖高度一致。

這個 eval 直接幫他們找到了一個架構問題: 用戶的 context 沒有完整地 propagate 到 pipeline 的每個階段。Summary prompt 有用戶的意圖，但後面 clustering 的 prompt 是通用的「從這些摘要中提取 category」，沒有帶入用戶的分析目標。修正之後，reverse engineering 分數大幅提升。

怎麼確認你的 Eval 真的有用

他們用了一個很聰明的 sanity check: 換一個更差的模型，eval 分數應該要下降。

如果把核心 LLM 從 GPT-4 換成 GPT-4o-mini，結果 eval 分數沒掉，那你的 eval 就有問題 — 它根本沒在量測模型能力的差異。這是一個簡單但非常重要的 eval 品質測試。

用 Coding Agent 連結 Eval 和 Code

另一個很實用的技巧: 把 eval 結果丟進一個有完整 repo access 的 coding agent（例如 Claude Code），讓它根據 eval 數據分析哪裡可能有問題。就是靠這個方法，他們發現了 context propagation 的 bug。

生產資料 » 合成資料

Clio 論文的作者 Miles 大量使用合成資料做 eval — 讓 Claude 生成資料，然後 cluster 它，再跟 ground truth 比對。Insights Agent 團隊一開始也試了，但發現:

生產資料比合成資料 messy 太多了。你會有超長的 trace、使用者在對話中途修正 agent、主題飄移… 在合成資料上表現好的演算法，在生產資料上可能完全不一樣。

所以他們所有的 eval 都只用生產資料。

從研究論文到生產的三個原則

Anika 最後總結了三個從 Clio 論文到 Insights Agent 的關鍵原則，我覺得這不只適用於這個產品，對任何想把研究 idea 做成產品的團隊都有用:

1. 先在 N=1 上證明價值

他們從 Chat LangChain（自家 chatbot）開始。不是一開始就想「怎麼做一個通用的 clustering 工具」，而是「在這個特定的資料集上，結果對我們有用嗎？」

第二個 use case 是客服團隊主動跑來問「我們也可以用嗎？」 — 這時候演算法還是針對這兩個場景特別調的。聽起來有點 counterintuitive（你不是應該要通用化嗎？），但道理是: 在你確定對兩個真實場景都有用之前，不要急著抽象化。

2. Eval 要量測有用性，不只是正確性

上面已經講了。核心是: correctness 是必要條件但不充分。你需要直接量測「使用者會不會覺得這個結果能幫他做決策」。

3. Dog-fooding 跟使用者反饋怎麼做都不嫌多

每一個重大的設計決策 — 從放棄 embeddings、到簡化配置、到加入 filtering、到從 topic clustering 轉向 debugging — 都來自 dog-fooding 和使用者反饋，不是團隊坐在辦公室想出來的。

Anika 的反思:

你很容易花很多時間去解決使用者根本不在意的問題，同時漏掉他們真正需要的。你很容易做出對你（建造者）來說「直覺上很簡單」但對第一次看到的人「完全搞不懂」的東西。

最早的版本是一個 Streamlit MVP — 連正式 UI 都沒有。但他們就是拿那個去收集反饋。你可以比你想像中更早把東西放到人面前。

跟 Multi-turn Evals 的搭配

Insights Agent 和 Multi-turn Evals 是互補的:

  Insights Agent Multi-turn Evals
範圍 跨多個 thread 找 pattern 評估單一 thread 品質
回答的問題 “發生了什麼?” “這次對話做得好嗎?”
輸出 類別層級結構 每個 thread 的分數
時機 On-demand（30 分鐘） 自動，每個 thread 完成後

實際工作流: Insights Agent 發現「Retrieval Questions」類別的滿意度偏低 → 對這類 thread 設定 Multi-turn Eval 持續打分 → 過濾低分的丟進 annotation queue → 人工 review 找到具體問題 → 修完後用 eval 分數驗證改善。

不只是 Agent Trace: 更廣的應用場景

一個有趣的發展是，Insights Agent 的分析對象已經不限於 LangSmith 上的 agent trace 了。LangChain 在 Python SDK 中加了 generate_insights() 方法，讓你把任意來源的對話資料上傳到 LangSmith 跑分析:

from langsmith import Client

client = Client()
report = client.generate_insights(
    chat_histories=your_data,  # 任意來源的對話資料
    name="Customer Support Topics",
    instructions="What are the main topics users are asking about?",
)

背後的機制是: SDK 會先把你的資料上傳成 traces 到一個新的 LangSmith project，然後在 LangSmith 上跑 Insights Report，最後回傳 UI 連結。所以分析本身仍然跑在 LangSmith 服務端，但資料來源可以是任何東西。

Anika 在演講中示範了幾個例子:

  • YouTube 留言: 抓所有提到 LangChain 的影片留言做分類，發現 YouTube 觀眾大多是「頂部漏斗」的學習者和實驗者，沒有那麼多人真的在部署 agent
  • GitHub issues: 自動分類 issue 的主題和嚴重程度
  • 客服工單 / Linear tickets / Email: 系統化理解問題分佈

他們甚至在想: 如果能把你跟 ChatGPT 或 Claude 的所有對話匯入，生成一份「Spotify Wrapped」風格的年度對話摘要，那也挺有趣的。

逆向工程分析的作者也指出，這個「自然語言 → LLM 驅動 pipeline → 人類可讀 insight」的架構模式本身是通用的，不一定要依賴 LangSmith — 類似的設計可以應用在 bug report 分類、用戶回饋綜合、code review pattern 偵測、安全事件 clustering 等場景。

實際效果: 20 小時 vs 15 分鐘

一個叫 Ryan 的 LangChain 社群成員分享了一個很有說服力的對比: 他手動標注了幾百筆 trace，花了大約 20 小時做分類和 error analysis。然後用 Insights Agent 跑同一批資料，15 分鐘完成，重建了他手動發現的 89% 的 error modes。

不是 100%，但考慮到時間差異（20 小時 vs 15 分鐘），這個 trade-off 對大多數場景來說非常值得。

逆向工程分析中也提到 Chat LangChain 自己的 ROI:

  • Before: 每週花 4 小時手動 review 500 筆 trace，只能看到明顯的 pattern
  • After: 20-30 分鐘跑一次 report，發現 35% 的問題是產品區分相關（LangChain vs LangGraph vs LangSmith）→ 加了比較文件 → 基礎問題減少了 22%
  • 節省: 每週 3.5 小時 + 使用者體驗改善

對大多數每天 100+ traces 的 production agent 來說，第一週就能回本。

一個有趣的平行實驗

Jason Liu（Instructor 的作者，也是這場演講的主持人）自己也在做類似的事，但用完全不同的方式: 他建了一個 CLI 工具做 clustering，然後把整個 CLI 丟給 coding agent（Codex、Claude Code），讓 agent 自己跑指令、看 cluster、分析 insight。

他最近還加了搜尋功能 — 不只能搜 topic name，還能用 embedding 或 full text search 搜 trace 內容。但他坦承，目前的觀察是: AI 可以寫出正確的分析 code，但產出的 insight 沒有特別 novel — 大多是他自己也能想到的東西。不過也有驚喜: 在一個紅隊測試（red teaming）資料集中，AI 發現了一群人專門嘗試讓 AI 角色扮演特定人物並說出帶有種族偏見的話，這是他事先不知道的 use case。

這呼應了 Insights Agent 的核心價值: 不是做你已經知道的分析，而是發現你不知道自己不知道的東西。

實用指南: 什麼時候該用、怎麼問

適合的場景:

  • ✅ Agent 已上線幾天/幾週（有足夠資料）
  • ✅ 想發現未知的 pattern（不是驗證特定假設）
  • ✅ 需要決定下一步優先改什麼
  • ✅ 手動看 trace 已經看不過來（每天 100+ traces）

不適合的場景:

  • ❌ 上線前測試（用 offline evals）
  • ❌ 即時監控（太慢，用 dashboard + multi-turn evals）
  • ❌ Debug 已知的特定問題（用 trace search）
  • ❌ 流量很低的 agent（< 50 traces 統計意義不大）

建議的問法:

Discovery 類:

  • 「What questions are users asking?」
  • 「How are users trying to use this agent?」

品質類:

  • 「Where is my agent making mistakes?」
  • 「What causes user frustration?」
  • 「Where do conversations fail to resolve?」

效能類:

  • 「Which interactions take longest?」
  • 「What causes retry loops?」

產品類:

  • 「What features are users asking about most?」
  • 「What documentation gaps exist?」
  • 「What unexpected use cases appear?」

迭代策略:

  1. 第一次跑寬問題:「What are users asking?」→ 發現 top categories
  2. 第二次聚焦:「Where is [specific category] failing?」→ 用 filter attributes 深入特定類別
  3. 找到問題 → 加進 annotation queue → 人工 review → 修復 → 重跑驗證

團隊分工:

  • PM: 每週跑一次追蹤使用趨勢
  • 工程師: 部署後按需跑，看有沒有 regression
  • 客服: 過濾負面情緒的 category，加入訓練資料

目前的限制和未來方向

根據文件、blog 和演講提到的 roadmap:

  • Executive Summary: 類似 Spotify Wrapped 風格的頂層摘要，highlight 最重要的 trace（已上線，報告頂端會顯示 key findings 和可點擊的 trace reference）
  • Episodic analysis: 目前只分析單次 report 的 snapshot，未來要加 trend analysis 來比較不同時期的變化
  • 自動修復: 現在 Insights Agent 只告訴你問題在哪，未來可能根據分析結果自動建議 prompt 優化
  • Incremental updates: 目前每次都要重跑，未來可能支援增量更新
  • Cross-project comparison: 比較不同 agent 的 pattern

還有一些技術上尚未公開的細節:

  • Embedding model 具體用哪一個（推測是 OpenAI text-embedding-3 或類似的）
  • Clustering 演算法的精確實作（推測是 HDBSCAN 或 Ward’s method hierarchical clustering）
  • Embedding 跟行為特徵、自定義 attributes 具體怎麼組合成特徵向量
  • Rate limiting 和 LLM call 的並行策略
  • 挫折感偵測的完整 regex pattern list

核心演算法目前不開源。你可以透過 LangSmith Python SDK 的 generate_insights 方法來呼叫，但 pipeline 本身跑在 LangSmith 的服務端。目前僅限 Plus 和 Enterprise tier 的 LangSmith 用戶使用。

一個很好的應用場景: 用數據決定要不要投資 5 個月的工程

演講 Q&A 中有一個很實際的例子。一個在做醫療 chatbot 的觀眾分享: 他們的 agent 幫病人回答問題，但病人會問「我下週二看的是哪個醫生？」、「我想補藥」這類需要整合醫院日曆系統和處方系統的問題。目前 agent 只能說「我無法處理，轉客服」。

問題是: 整合醫院的日曆系統可能要花 5 個月的工程。值不值得？

如果能用 Insights Agent 跑一次分析，發現 40% 的對話都在問日曆相關的問題 — 那可能值得投兩個工程師去做。如果只有 2%，那還不如把資源拿去做 DocuSign 表單提醒。

這就是 Insights Agent 最務實的價值: 把「我覺得這個功能很重要」變成「數據告訴我 X% 的使用者需要這個功能」，讓工程投資的決策有依據。

回頭看整篇，我覺得 Insights Agent 最有價值的 takeaway 不是技術架構本身（雖然 pipeline 設計得很好），而是這三件事:

  1. Embedding similarity ≠ useful similarity — 放棄 embeddings 轉用 LLM 分類，是被真實資料逼出來的決定
  2. Eval 要測有用性不只正確性 — vagueness、pairwise consistency、reverse engineering user goal 這三個 eval 的設計思路很值得借鑒
  3. Configuration 是 crutch — 如果你的系統需要使用者做很多配置才能給出好結果，那問題在系統不在使用者

對想做類似 agent observability 工具或 LLM-driven analytics 的團隊來說，這整個從 Clio paper → Streamlit MVP → 生產產品的旅程蠻值得參考的。

參考: