變現、定價與「成本 ↔ 品質」實驗

1. 為什麼現在就要思考變現

在此模組之前，核心問題是「這東西到底能不能動？」。現在我們加上一個層次：「那它划不划算？」。

對 LLM 應用來說這特別痛：可變成本（LLM tokens、rerank 模型、embeddings）會把你弄得暈頭轉向，不再是你習慣的「$20 的伺服器加 $15 的 Postgres」。忽視這件事，就等著在月底收到一張來自 OpenAI、堪比房貸的帳單。

所以今天有三個大主題：

1. ChatGPT App（以 GiftGenius 為例）有哪些變現模型。
2. 如何把 pricing ↔ cost_per_task 連起來，避免賣出「100 次禮物推薦只要 $1」這種方案，當其中一次推薦本身就要 $0.15。
3. 如何設定A/B 實驗「成本 ↔ 品質」：更換模型、調整 prompts、改 UX，並用正確的日誌把它記下來，好在幾週後能依據數據而非感覺做決策。

同時我們也在為下一個關於 LLM‑evals 與 quality_score 的模組鋪墊，但本講不會深入到程式碼。

2. ChatGPT App 的變現模型：B2C、B2B、Freemium 與 Upsell

撇開 LLM 的魔法，這裡的變現模型和一般 SaaS 或行動 App 很像。不過 conversational 介面有其特性：使用者常常感受不到「哪裡免費、哪裡付費」，這點需要在 UX 上小心設計。

我們以 GiftGenius 來看幾種主要選項。

B2C：一般使用者與送禮

這裡的客戶是一般人，他們來到 ChatGPT 說：「幫我為太空迷找一個 $50 的禮物」。你不一定要賣自己的商品，而是只做推薦給使用者。

常見的 B2C 模式：

1. 一次性購買。
   使用者為特定情境付費。例：免費 3 個點子，再來是付費「套裝」，為同一收禮者多給 10 個點子。
2. 訂閱。
   每月付費取得存取權。對 GiftGenius 而言，可能是「每月最多 100 次推薦」或「經常送禮者的無限推薦」。
3. Freemium（free vs paid tiers）。
   基本情境免費（每月最多 N 次推薦、功能縮減），付費則提供更多額度、更強的模型、更多推薦格式與歷史紀錄。這是 ChatGPT App 最典型的模式：「在 ChatGPT 內基本功能免費，進階功能付費」。
4. App 內 Upsell。
   使用者先做免費的基本推薦，看到結果不錯，你就溫和地提議：「要不要花 $X，做更深入的推薦（考慮願望清單、社群資料等等）？」或「直接購買禮物禮券」。

B2B：團隊、公司與企業送禮

這時會介入人資（HR）、行銷部門，以及「負責員工／客戶禮物的人」。

典型組合：

• 按使用者授權（per seat）。
  例如「HR‑Team」方案給 10 人，每人可使用 GiftGenius，並有禮物與預算報表。
• 按公司授權（per company）。
  「最多 500 名員工，固定月費，內部推薦次數不限」。
• 額外 enterprise 功能。
  獨立後台、與 HRIS/CRM 的整合、客製報告、SLA。

兩種情況下，你不是算「一次推薦多少成本」，而是看 cost_per_user_per_month 或 cost_per_tenant_per_month，再和授權價格相比。

如何為 GiftGenius 選擇模型

為避免陷入理論，先來個簡單起步方案：

• B2C：Freemium。
  每月 3 次推薦免費；之後每月 $5 訂閱，無限推薦並使用進階模型。
• B2B：按公司。
  「HR‑團隊」資費每月 $99，包含最多 500 次員工推薦、整合 HR 系統與報表。

等到有了 cost_per_task 與轉化率的真實數據，再來調整。現在這些數字基本是「拍腦袋」：看起來合理，但我們還沒真的驗證一次完成的情境要花多少。下一節會把這些資費與真實成本連起來——也就是 cost_per_task。

3. 價格與成本的關聯：什麼是 cost_per_task

接著來到最重要的：如何避免把自己變成 GPT‑5 慈善基金。

直覺：價格 ≥ cost_per_task × 利潤率

在上一節你已經看到 cost_per_task 這個概念——它是一個成功情境的總成本：從「使用者開始推薦」到「拿到結果」（以及可能完成付款）。

它包含：

• LLM 成本（tokens × 入口／出口的 price_per_token，可能包含 rerank 模型、embeddings 等等）；
• 分攤到單一任務的基礎設施成本（伺服器、資料庫、佇列、MCP 閘道）——通常依彙總數據估算；
• 需要的話——交易成本（Stripe 手續費、詐欺檢查），如果你把 cost_per_task 算到「到手金額」之前。

核心想法很簡單：單次情境或訂閱的價格，應高於單次情境的平均成本，並乘上一個「利潤緩衝」。

極度簡化的話：

price_per_task >= cost_per_task * ( 1 + margin )

不需要用一堆百分比把講義塞滿，記住這個直覺規則就好。

GiftGenius 的例子

假設你已經實作了上一堂課的成本日誌，並且有彙總報告：

• 平均 cost_per_task（一次完成的禮物推薦）＝ 0.15 USD；
• 其中已包含 LLM tokens（多次 suggest_gifts 呼叫、rerank 與最後的 summary）與基礎設施分攤。

接著你觀察情境：

• 免費使用者會做推薦，有時會買 $50 的禮物禮券；
• 在完成推薦的情境裡，假設購買轉化率是 5%。

先不進入完整的單位經濟學，但可以粗估：如果 100 次推薦中：

• 你花了 100 × $0.15 ＝ $15；
• 其中 5 次完成了 $50 的結帳；
• 營收 5 × $50 ＝ $250。

看起來不錯：粗算是（$250 – $15），再加上 Stripe 佣金、稅務與其他痛點。但要注意，若訂閱太佛（比如 100 次推薦賣 $1），很容易直接變成負毛利。

迷你程式碼範例：在 TypeScript 中保存 cost_per_task

假設你有一個 MCP tool，負責完成推薦流程，並知道整體成本：

// 最終情境指標的型別
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// 簡單的指標記錄函式
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// 在完成推薦的處理器某處：
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // 由 token 計算
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

這樣的日誌很容易在儀表板聚合，觀察不同模型、使用者、情境的 cost_per_task 分佈。

4. Pricing：如何把 cost_per_task 換算成實際價格

現在有了 cost_per_task，接著要決定對使用者「怎麼收」與「收多少」。

B2C 的簡單規則

對 B2C 可以採用經驗法則：

「我們願意把 LLM + 基礎設施的成本控制在不超過營收的 X%。」

例如你決定不想讓 LLM 成本超過營收的 20%，那麼：

• 若 cost_per_task ＝ $0.15，單次付費情境的最低價格約為 $0.75，讓 0.15 大約是 0.75 的 20%；
• 若你賣訂閱，就估計每位訂閱者每月的平均情境數，再相乘。

一開始「用感覺」很正常，等有真實數據再微調（劇透：不會很快來）。

B2B 的簡單規則

在 B2B 通常看：

• cost_per_user_per_month 或 cost_per_tenant_per_month；
• 企業願付程度（你解決問題的價值大小）。

例如，如果 HR 團隊透過 GiftGenius 每年要處理數萬美元的禮物，$99/月的訂閱就顯得相當克制，即使你對這個團隊的 LLM 成本只有 $10/月。重點是要避免 cost_per_tenant ＝ $80，而訂閱只有 $50 的局面。

沒錯，這種事會發生，特別是抱持著「我們是 AI，先全部免費，之後再說」的心態時。

伺服器上一個小小的「守門員」函式

你可以直接在程式裡放個簡單的「guard」，當你設定價格時提醒你成本是否還在合理範圍：

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // 例如，0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// 範例：
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — OK，20% <= 30%

這不會取代完整財務模型，但能提供快速的 sanity‑check（直覺檢查），尤其在你嘗試不同價格時特別有用。

5. 實驗：「模型／代理」對成本與轉化的影響

現在進到最有趣的部分：A/B 實驗。

直覺很簡單：

• 變體 A —— 昂貴的模型／較複雜的 workflow；
• 變體 B —— 便宜的模型／簡化的 workflow；
• 我們想同時了解它們對以下面向的影響：
  • cost_per_task，
  • 結果品質（使用者體感與未來的 LLM 評分），
  • 商業指標（轉化率、營收）。

要對哪些東西做實驗

三條主要軸線：

1. 模型。
   例如 GPT‑5 vs GPT‑5‑mini 或其他系列。通常昂貴的模型帶來更好的品質與更高的 cost_per_task，便宜的模型相反。
2. 代理邏輯／prompts。
   步驟更細、prompts 更長、reasoning 更複雜——品質更好，但更貴；極簡邏輯——更便宜，有時品質差不多。
3. UX 形式。
   冗長的精靈式流程 vs 快速的 inline 模式。即便模型相同，token 與步驟數也可能差數倍。

以上這些你都能開始實作，重點是把它們包成有日誌的實驗。

實驗要記錄哪些欄位

在你為成本記錄的欄位（tokens、model、cost_estimate、user_id、request_id 等）之上，加上實驗欄位：

• experiment_id —— 實驗的唯一 ID（例如 "gift_model_ab_2025_11"）。
• variant —— 使用者所屬分支："A"、"B"、"control"、"treatment" 等。
• model_name 或 agent_version —— 以免事後忘記當下的配置。
• 情境的結果：
  • 是否有 workflow_completed；
  • 是否有 checkout_success；
  • 最終的 cost_per_task。
• 可選 —— quality_score（稍後會談，它是連到 LLM‑evals 模組的橋）。

實驗事件的 JSON 日誌範例

典型事件可能長這樣：

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

這類紀錄很容易被任何分析工具彙總：你可以做出「variant A vs B 在成本／轉化／收入上的比較表」。

程式碼範例：在 MCP 工具裡記錄實驗

想像你的 MCP 伺服器已計算好情境成本（cost_per_task），也知道使用者分配到哪個實驗分支：

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

在更上層你會決定使用者屬於哪個變體（依 user_id、tenant_id 或隨機），並把 ExperimentContext 傳入 workflow 處理器。在這一層，我們已經固定了實驗該怎麼記：需要哪些欄位、在哪裡寫。接下來會談如何把這些實驗轉成清楚的產品假設與定價決策，而非只是一堆日誌。

6. 稍談 quality_score 與 LLM‑evals

更詳細的內容會在第 20 模組，這裡先分享概念：quality_score 是對回答／方案的品質評分，例如 0 到 10，通常由另一個充當「裁判」的 LLM 模型來打分。LLM‑as‑judge 的細節我會在第 20 模組說明。

實作細節先不管——那是下一個模組的主題——現在重要的是理解概念：

• 除了金錢，我們還想衡量品質；
• 我們可以請人，或是請第二個模型來評分：「GiftGenius 的禮物推薦有多好（0–10 分）？」；
• 接著我們觀察 quality_score 與下列指標的關聯：
  • 購買轉化；
  • 使用者留存；
  • willingness‑to‑pay（願付價格）。

在日誌角度，它只是另一個欄位：

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10，可能為 undefined
};

本講先到這裡：LLM‑evals、golden cases 與「LLM‑as‑judge」會在後續課程深入。現在只要知道這個 score 要放到實驗哪裡就夠了。正是 quality_score 能幫你避免「只優化成本」的經典錯誤：它讓你看見在哪裡把情境壓得太便宜，品質開始下滑，連帶拖累轉化與營收。

7. 如何用實驗來推動定價與變現

接下來不只是記錄實驗，還要把它們整理成清楚的商業假設，附上成功指標與對變現的影響。只記 experiment_id 還不夠：重要的是把產品改動當成具體假設，並明訂成功指標。

範例假設：昂貴模型 vs 便宜模型

以 GiftGenius 為例的實驗：

• 變體 A —— 昂貴模型（GPT‑5），更豐富的 reasoning、較長的精靈式流程。
• 變體 B —— 便宜模型（GPT‑5‑mini），較簡單的 prompt 與更短的對話。

假設：換成便宜模型會讓 cost_per_task 至少下降 50%。同時使用者體感與 LLM 評分（我們的 quality_score）下降不超過 5–10%，而且購買轉化不會下滑。

技術上，每個 task 你都會記錄和第 5.2 節相同的欄位：

• experiment_id = "gift_model_ab_2025_11"；
• variant = "A" 或 "B"；
• model_name；
• cost_per_task_usd；
• workflow_completed；
• checkout_success；
• quality_score（等有 LLM‑evals 後）。

一兩週後你可以：

• 比較 A 與 B 的平均 cost_per_task；
• 比較 checkout‑rate（成功付款的比例）；
• 比較平均 quality_score（若有）。

若 B 幾乎不輸在品質，但便宜兩倍，你可以：

• 切到 B，提升毛利；
• 或維持你的成本結構，調降售價／訂閱價以推動成長。

範例假設：高品質的 upsell

另一個假設：若在免費 3 個點子之後，提供一個高級 upsell——「完整禮物報告 + 賀卡文案建議」售價 $4.99，購買轉化至少提高 2 個百分點（2 p.p.）。同時 cost_per_task 增加不超過 $0.05。

這個實驗不那麼關於模型，更關於UX 與產品邏輯。但技術上仍如前：

• 用 variant 區分不同 UX；
• 記錄每個情境的 cost 與 revenue；
• 分析 uplift（新邏輯帶來多少收入而不讓成本爆炸）。

程式碼範例：記錄每個任務的簡單營收

有時把營收與成本放在一起記會比較方便：

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

之後用 taskId 把 task_revenue 與 experiment_task_result 關聯，就能為每個變體計算：

• 平均 revenue_per_task；
• 平均 cost_per_task；
• 並且算最基本的 ROI。

8. 實作練習：為 GiftGenius 做 A/B 實驗

為了把理論落地，我們就直接口頭走一次「昂貴 vs 便宜模型」的實驗步驟，當成實作練習。

我們要改什麼

• 變體 A：
  • 模型 gpt-5；
  • 更詳細的 system‑prompt 與代理步驟；
  • 可能更多中間 reasoning 呼叫。
• 變體 B：
  • 模型 gpt-5-mini；
  • 更精簡的 prompt；
  • 更少的輔助 tool 呼叫、簡化流程。

如何把使用者分配到分支

最簡單的方法——對 user_id 做 hash：

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

這樣能保證大致均勻分配，且同一使用者總是會進到同一個變體。

要記錄什麼

在推薦 workflow 完成時，記錄和前幾節（5.2 與 7.1）相同的欄位，並加上營收：

• experiment_id = "gift_model_ab_2025_11"；
• variant 來自上面的函式；
• model_name，實際使用的模型；
• cost_per_task_usd，tokens 與基礎設施的總成本；
• workflow_completed（true/false）；
• checkout_success（true/false）；
• revenue_usd（0 或購買金額）。

可選（之後課程會加入）的是 quality_score。

這些資料會進入你的日誌／分析系統，你可以把它們整理成表格：

從這張表可以看到，B 幾乎帶來一樣的收入，但成本只有一半，這就是非常有力的論點。

9. 視覺圖：「成本 ↔ 品質 ↔ 變現」的輪廓

為了把概念整合起來，畫一張小圖示意「資料怎麼流」：

flowchart TD
    U[使用者於 ChatGPT] --> A["ChatGPT App (GiftGenius)"]
    A --> E[實驗模組
指派變體 A/B]
    E --> AG[代理 / MCP 工具
使用不同模型]
    AG -->|LLM 呼叫| L[使用量與成本日誌]
    AG -->|推薦結果| UI[小工具 / 聊天回覆]
    UI -->|行為：點擊、購買| BE[Commerce backend]

    L --> M[指標：cost_per_task,
cost_per_user]
    BE --> M
    M --> D[定價與實驗的儀表板]

    subgraph "後續模組 20"
      J[LLM‑法官
quality_score]
      J --> M
    end

你現在正好位於這張圖的中間：會記錄成本與營收，並在此基礎上加入實驗與定價。下一個模組會出現主題「Judge Dredd」（LLM‑法官）。

10. 變現與實驗常見錯誤

當腦中有了整體輪廓，就更容易看出常見的坑。下面是一份常見錯誤清單，做變現與成本實驗時可以對照檢查。

錯誤 1：只優化成本，忘了品質。
常見情境：你換成更便宜的模型，看到 OpenAI 帳單變漂亮，就宣布勝利。結果一個月後發現使用者更少購買禮物禮券、回訪率下降、客服抱怨「推薦一堆沒用的東西」。如果不記錄 quality_score，甚至連代理指標（點擊、收藏、轉化）都不看，很容易走向「便宜但沒價值」。

錯誤 2：只把 LLM 算進 cost_per_task，忽略基礎設施與支付。
有時工程師很仔細地算 token，卻忘了 Redis、佇列、第三方 API、Stripe 手續費等。結果 cost_per_task 被大幅低估，價格看起來比實際更寬鬆。基礎設施通常用彙總數據來估，但它的分攤仍必須算在情境成本裡。

錯誤 3：更改模型／UX 卻不標註 experiment_id 與 variant。
「我們微調了 prompt，感覺更好了」——一個月後沒人記得改在什麼時候、依據哪些數據、帶來什麼結果。若日誌中沒有明確標示（experiment_id、variant），也沒有綁到特定版本釋出，就難以做回溯分析、也難證明改善不是偶然。

錯誤 4：資料太少或太早就下結論。
如果實驗跑兩天，你就根據十筆付款認定模型 B「更划算」，這是典型的統計雜訊。至少要有最小觀察期——一週更好——並累積足夠的情境數量來比較平均值與轉化。在本講我們不深入統計，但請記住「不要用 5 個事件就做結論」。

錯誤 5：複雜的定價卻沒有簡單的心智規則。
你可以設計三層資費、不同幣別與推薦碼折扣，但卻沒有簡單的原則，例如「LLM 成本不超過營收的 X%」或「情境單價不得低於平均 cost_per_task 的 3 倍」。沒有這類護欄，很容易把毛利弄丟，還要到月底才發現。

錯誤 6：忘了把變現和行銷／成長連起來。
變現與定價不會在真空中運作：訂閱越貴，流失越高、轉化越低；價格越低，對成本優化的要求越高。錯誤在於只看「我們現在賺多少」，卻沒有把它和 acquisition／activation／retention 指標連在一起，這會在本模組的下一個主題談到。定價實驗最好用和品質／成本實驗相同的口徑記錄，才能看到全貌。