為你的 Lovable 應用程式微調支援機器人(生產環境零 API 費用)
構建一個真正了解你產品的 AI 支援機器人——在你的文件、票券、語氣上訓練。然後在本地運行,持續 API 費用為零。
每個 Lovable 應用程式最終都需要客戶支援。標準做法是插入帶有滿滿文件的 GPT-4 系統提示。你把溫度調低,告訴它要樂於助人,然後期待最好的結果。它能用——某種程度上。但每次對話花費 $0.03 到 $0.06,每週至少一次幻覺你的定價頁面,而且完全不知道你三個月前把「Pro Plan」重命名為「Growth Plan」了。有更好的方法。
如果你 的支援機器人真正了解你的產品呢?不是「我爬了你的 FAQ」的意義上,而是「我在 500 次真實支援對話上訓練過,我知道你的用戶遇到的確切邊緣案例」的意義上。這就是微調給你的。當你用 Ollama 在本地部署微調後的模型時,每次對話的成本從 $0.04 降到恰好 $0.00。
本指南演示整個過程:收集你的訓練資料、使用 Ertas 微調模型、在本地部署、並將其整合到 Lovable 構建的應用程式中。不需要 ML 背景。不需要 GPU 叢集。不需要持續的 API 帳單。
為何通用 LLM 在支援機器人上表現不佳
讓我們坦誠說說當你把 GPT-4 指向你的產品文件並讓它回答客戶問題時會發生什麼。
它幻覺產品細節。 問它定價,它會自信地陳述六個月前有效的數字——或從來不是真的數字。問某個功能限制,它會發明一個不存在的解決方案。通用 LLM 不了解你的產品。它們了解「回答 SaaS 產品問題」的一般模式,並用聽起來合理的捏造填空。
它的語氣不一致。 一次對話聽起來像矽谷行銷頁面。下一次聽起來像 Wikipedia 文章。你的支援機器人應該聽起來像你的品牌。通用模型聽起來像它們自己。
規模擴大時很昂貴。 以下是 GPT-4o 支援對話的計算:
| 對話/月 | 平均 Tokens/對話 | 每月 API 成本 |
|---|---|---|
| 500 | 約 2,000 | $15 - $30 |
| 2,000 | 約 2,000 | $60 - $120 |
| 5,000 | 約 2,000 | $150 - $300 |
| 10,000 | 約 2,000 | $300 - $600 |
| 25,000 | 約 2,000 | $750 - $1,500 |
每月 10,000 次對話,你在支援機器人推論上花費 $300 到 $600。對於收取 $9.99/ 月的獨立應用程式,這是顯著的利潤打擊。與你的託管成本呈亞線性增長不同,API 成本隨每一次對話線性擴展。
它不隨時間改善。 你的人工支援代理會學習。他們看到同樣關於 CSV 匯出錯誤的工單十二次,解決速度越來越快。GPT-4 機器人從一次對話到下一次什麼都不學。每次互動都從零開始。
微調修復了所有四個問題。在你實際支援資料上訓練的模型了解你的產品細節、保持一致的語氣、以零每 token 成本在本地運行,並可在你的產品演化時重新訓練。
更好的方法:在你的支援資料上訓練的模型
微調不是關於讓小型模型在一般意義上更聰明。而是關於讓它成為一個狹窄領域的專家:你的產品、你的用戶、你的邊緣案例。
在 400 個來自你實際產品的高品質支援對話上微調的 7B 參數模型,對你的特定支援使用案例將一貫優於帶系統提示的 GPT-4。為什麼?因為:
- 它見過你的用戶真正問的問題,而不是假設的問題
- 它了解你確切的功能集、限制和定價
- 它從數百個範例中學習了你的品牌聲音
- 它處理你的特定邊緣案例,因 為它是在這些案例上訓練的
代價是它在其他方面會更差。讓它寫詩,它可能會試圖排查你的帳單頁面。但這就是整個重點。你不需要你的支援機器人寫詩。
收集你的訓練資料
你需要輸入-輸出配對:一個客戶問題和理想的支援回應。以下是找到它們的地方。
來源 1:以前的支援票。 如果你一直在手動做支援(電子郵件、Intercom、Crisp,任何都好),你坐在一個金礦上。匯出你的票歷史。每張已解決的票都是一個潛在的訓練範例。專注於客戶確認問題已解決的票——這些代表成功的支援互動。
來源 2:你的幫助文件。 將每篇幫助文章轉換為問答對。對你文件的每個部分,寫 3-5 個用戶可能問的問題,這個部分能回答,然後寫出理想的回應。20 頁的幫助中心可以生成 60-100 個訓練範例。
來源 3:你的 FAQ。 類似於文件,但這些已經是問答格式。將每個 FAQ 答案擴展為對話式支援回應,而不是文件式答案。
來源 4:合成生成。 這是在你沒有大量票歷史時引導的秘密武器。使用 GPT-4 生成關於你產品的真實客戶問題,然後手動撰寫(或編輯)理想的回應。關鍵詞是「手動」。你在策劃回應,而不是自動生成它們。
以下是合成生成的具體工作流程:
- 給 GPT-4 你的產品描述、功能列表和定價頁面
- 要求它跨類別生成 50 個真實的支援問題(帳單、錯誤、功能、操作方法、帳戶管理)
- 對每個問題,自己撰寫理想的回應——或讓 GPT-4 起草一個你然後為準確性和語氣進行編輯的版本
- 審查每一個配對以確保正確性
來源 5:你的更新日誌和已知問題。 用戶不斷問最近的更改和已知錯誤。為每個更新日誌條目和每個已知問題創建問答對。
構建你的資料集
你的訓練資料需要是 JSONL 格式,每行代表一個訓練範例。對支援機器人,格式如下:
{"input": "I upgraded to the Growth plan but I'm still seeing the free plan limits. It's been 24 hours.", "output": "Thanks for reaching out! Plan upgrades can take up to 10 minutes to propagate, but 24 hours definitely isn't right. Let me check a few things: First, can you try logging out and back in? This forces a session refresh that picks up plan changes. If that doesn't fix it, go to Settings > Billing and confirm the plan shows as 'Growth' there. If it still shows 'Free,' the payment may not have completed — check your email for a receipt from Stripe. Let me know what you see and I'll get this sorted."}
{"input": "How do I export my data as CSV?", "output": "You can export to CSV from the Dashboard page. Click the three-dot menu in the top right corner of any data table, then select 'Export > CSV.' The file will download immediately for tables under 10,000 rows. For larger datasets, you'll get an email with a download link within a few minutes. Note: CSV exports are available on the Growth plan and above. If you're on the Free plan, you can export up to 100 rows at a time."}你需要多少個範例? 對於專注的支援機器人,目標是 300 到 500 個高品質範例。這足以涵蓋:
- 50-80 個常見的操作方法問題
- 30-50 個帳單和帳戶問題
- 40-60 個錯誤報告和故障排除流程
- 30-40 個功能請求和變通方案解釋
- 20-30 個入門問題
- 其餘的邊緣案例和雜項
品質比數量更重要。你訓練集中的每個回應都應該恰好是你希望機器人說的。如果你不會把那個回應發送給真實的客戶,就不要包含它。
資料集衛生提示:
- 移除個人身份資訊(姓名、電子郵件、帳戶 ID)
- 標準化你的回應格式(問候風格、結語風格、詳細程度)
- 包含機器人優雅地處理它無法回答的問題的範例(「我建議聯繫我們的團隊 support@yourapp.com 以解決特定帳戶的帳單問題」)
- 添加機器人以同理心處理沮喪或不安用戶的範例
使用 Ertas 微調
這是聽起來很可怕但實際上只需要約 15 分鐘的部分。
第 1 步:上傳你的資料集。 登入 Ertas 並前往 Studio。上傳你的 JSONL 文件。Ertas 將驗證格式並標記任何問題——格式錯誤的 JSON、重複條目、可能沒有足夠信號的極短回應。
第 2 步:選擇你的基礎模型。 對支援機器人,Qwen 2.5 7B 是最佳點。它夠大,足以處理細緻的支援對話,但夠小,能在適度的硬體上運行。如果你在記憶體有限的機器上部署(8GB 或更少),考慮 Qwen 2.5 3B——它仍然會比針對你特定使用案例提示的通用模型表現好得多。
第 3 步:配置訓練。 使用 LoRA 微調(Ertas 中的預設值)。關鍵設定:
- Epochs: 300-500 個範例的支援資料集用 3-5 個
- 學習率: 保持在 Ertas 預設值,除非你有理由改變它
- LoRA rank: 16 對支援機器人是一個穩固的預設值
第 4 步:訓練。 點擊開始。在 Ertas 上用 LoRA 在 500 個範例上訓練 7B 模型通常需要 20-40 分鐘。你將看到損失指標實時更新。你希望看到損失曲線穩步下降並趨於平緩——而不是劇烈波動。
第 5 步:評估。 Ertas 提供評估介面,你可以根據樣本輸入測試你的微調模型。從你實際的支援隊列中嘗試 20-30 個問題,並將回應與你的人工代理所說的進行比較。注意:
- 事實準確性(它的定價正確嗎?)
- 語氣一致性(它聽起來像你的品牌嗎?)
- 邊緣案例處理(它對它沒有訓練過的問題做什麼?)
如果結果不令人滿意,修復幾乎總是更好的訓練資料,而不是更多的訓練資料。返回並改進你的資料集——修復不正確的回應,為薄弱領域添加更多範例,移除嘈雜的條目。
部署你的支援機器人
一旦你對模型滿意,從 Ertas 將其匯出為 GGUF 文件。這是 Ollama 用於本地推論的格式。
第 1 步:在你的伺服器上安裝 Ollama。 如果你在 VPS 上運行你的 Lovable 應用程式(DigitalOcean、Hetzner、Railway),安裝 Ollama:
curl -fsSL https://ollama.com/install.sh | sh第 2 步:載入你的模型。
ollama create my-support-bot -f Modelfile你的 Modelfile 指向你匯出的 GGUF:
FROM ./my-support-bot.gguf
PARAMETER temperature 0.3
SYSTEM "You are the support assistant for [YourApp]. Be helpful, accurate, and concise."
第 3 步:測試它。
curl http://localhost:11434/api/generate -d '{
"model": "my-support-bot",
"prompt": "How do I upgrade my plan?",
"stream": false
}'第 4 步:驗證表現。 針對已部署的模型運行你的評估集,確認品質與你在 Ertas 中看到的一致。量化到 GGUF 偶爾會在邊緣影響品質——如果你注意到退化,嘗試更高的量化級別(Q6_K 或 Q8_0 而不是 Q4_K_M)。
與你的 Lovable 應用程式整合
你的 Lovable 應用程式可能已經有聊天小工具的前端組件。唯一的改變是將其指向你的本地 Ollama 端點而不是 OpenAI API。
選項 A:直接 API 呼叫。 如果你的後端是一個簡單的 API 路由,將 OpenAI SDK 呼叫換成對你的 Ollama 實例的 fetch:
// 之前:OpenAI API
const response = await openai.chat.completions.create({
model: "gpt-4o",
messages: [{ role: "user", content: userQuestion }],
});
// 之後:本地 Ollama
const response = await fetch("http://localhost:11434/api/chat", {
method: "POST",
body: JSON.stringify({
model: "my-support-bot",
messages: [{ role: "user", content: userQuestion }],
stream: false,
}),
});選項 B:OpenAI 兼容端點。 Ollama 在 /v1/chat/completions 暴露了與 OpenAI 兼容的 API。這意味著你可以在現有的 OpenAI SDK 配置中僅更改基礎 URL:
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "http://localhost:11434/v1",
apiKey: "not-needed", // Ollama 不需要 key
});
const response = await client.chat.completions.create({
model: "my-support-bot",
messages: [{ role: "user", content: userQuestion }],
});這種方法不需要對現有聊天小工具前端代碼做任何更改。回應格式完全相同。
成本比較:重要的數字
讓我們比較在 12 個月內使用 GPT-4o 和微調本地模型運行 AI 支援機器人的總成本:
| GPT-4o API | 微調本地(Ertas + Ollama) | |
|---|---|---|
| 設置費用 | $0 | $25/月 Ertas(或一次性訓練) |
| 基礎設施 | $0(OpenAI 託管) | $30/月 VPS(4GB RAM,Hetzner) |
| 每次對話費用 | $0.03 - $0.06 | $0.00 |
| 1K 對話/月 | $30 - $60/月 | $30/月固定 |
| 5K 對話/月 | $150 - $300/月 | $30/月固定 |
| 10K 對話/月 | $300 - $600/月 | $30/月固定 |
| 25K 對話/月 | $750 - $1,500/月 | $30/月固定 |
| 每年費用(10K/月) | $3,600 - $7,200 | $360 + $174 Ertas = $534 |
盈虧平衡點約為每月 1,000 次對話。低於此點,API 方式更簡單且更便宜。高於此點,節省每月複合。在每月 10,000 次對話時,你每年節省 $3,000 到 $6,600。
隨著你的應用程式增長和對話增加,API 成本線性上升,而本地模型成本保持固定。在每月 50,000 次對話時,API 每月花費 $1,500 到 $3,000。你的本地模型仍然花費 $30。
讓你的機器人保持更新
你的產品在變化。你的支援機器人需要跟上。工作流程是:
- 每月(或主要產品更改後)收集新的支援對話
- 添加 20-50 個涵蓋更改的新訓練範例
- 在 Ertas 上重新訓練(需要 20-40 分鐘)
- 匯出更新的 GGUF 並在你的伺服器上熱切換
以每月 $25 的 Ertas,你可以根據需要頻繁重新訓練。大多數團隊每月進行一次——每月重新訓練一次,使用上個月支援票的新範例。這讓機器人保持最新狀態,無需持續關注。
本週末開始
以下是最小可行計劃:
- 週六上午: 匯出過去 3 個月的支援票。將它們整理成 200-300 個 JSONL 範例(這是最難的部分——預算 3-4 小時)。
- 週六下午: 上傳到 Ertas,選擇 Qwen 2.5 7B,使用 LoRA 預設值訓練。訓練期間,啟動一個 $6/月的 Hetzner VPS 並安裝 Ollama。
- 週日上午: 匯出 GGUF,部署到你的 VPS,用 20 個樣本問題測試。
- 週日下午: 在你的 Lovable 應用程式中切換 API 端點。部署。完成。
總時間:一個週末。持續月費:$30 用於 VPS。從那時起的每次支援對話,AI 推論費用恰好為零。
你的支援機器人應該比 GPT-4 更了解你的產品。微調讓這成為可能,本地部署讓它免費。
延伸閱讀
- Fine-Tune a Model on Your App's Data — 獨立開發者微調的完整初學者指南。
- Your Vibe-Coded App Hit 10K Users. Now Your AI Bill Is $3K/Month. — 理解 AI 費用斷崖及如何避免它。
- Fine-Tune AI Without Writing Code — Ertas 如何讓非 ML 開發者也能微調。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $10/mo USD.
Keep reading
你的 Lovable 應用有個每月 $600 的問題
Lovable 讓構建 AI 應用變得輕鬆——直到你的 API 帳單到達。這裡是每位 Lovable 構建者需要看到的費用計算,以及讓 AI 費用在任何規模下保持穩定的解決方案。
Bolt.new 應用程式與 OpenAI 成本懸崖:規模化後會發生什麼
Bolt.new 讓添加 AI 功能變得簡單。以下是隨著用戶增長,您的 OpenAI 費用會發生什麼——以及如何用固定成本的微調本地模型替代它。
Claude Projects 與微調模型:各自勝出的時機
Claude Projects 提供持久化背景資訊和指令。微調模型將領域知識內化。以下說明各自的適用時機以及大規模部署的成本比較。