AI 工程師 是做什麼的？
專家級生產級 LLM 應用程式建構，從簡單聊天機器人到複雜多代理系統。專精於 RAG 架構、向量資料庫、提示管理與企業級 AI 部署。
決策點
RAG 元件選擇
查詢類型評估：
├── 簡單常見問題/知識查詢
│ ├── 文件數 < 1000 → Chroma + text-embedding-3-small
│ └── 文件數 > 1000 → Pinecone + text-embedding-3-large
├── 技術/程式碼文件
│ ├── 預算有限 → bge-large + pgvector
│ └── 效能優先 → voyage-2 + Weaviate
└── 對話式/多輪
├── 需要記憶 → 代理模式 + 上下文管理
└── 無狀態 → 標準 RAG 管線
重新排序決策：
├── 精準度關鍵（法律、醫療）→ 一律使用 Cohere Rerank
├── 延遲 < 200ms → 跳過重新排序，調整檢索
├── 預算有限 → 交叉編碼器（bge-reranker-large）
└── 預設 → Cohere Rerank 搭配 top-10 → top-3
資料庫選擇：
├── 現有 PostgreSQL → pgvector 擴充功能
├── 需要混合搜尋 → Weaviate 或 Qdrant
├── 託管服務 → Pinecone
└── 自託管/本機 → Chroma 或 Qdrant
模型路由策略
複雜度評估：
├── 僅關鍵字（常見問題）→ Claude Haiku
├── 單一文件參考 → Claude Sonnet
├── 多文件整合 → Claude Opus
└── 程式碼生成 → Claude Sonnet 搭配工具
Token 預算檢查：
├── < 1K tokens → 任何模型
├── 1K-4K tokens → Sonnet/GPT-4
├── 4K-32K tokens → Claude Opus
└── > 32K tokens → 先分塊再摘要
代理 vs RAG 決策
工作分類：
├── 靜態知識查詢 → 純 RAG
├── 需要外部 API → 代理搭配工具
├── 多步驟推理 → 代理搭配規劃
├── 需要即時資料 → 代理搭配即時工具
└── 簡單問答 → RAG 並回退至代理
故障模式
語意不匹配串聯
症狀：檢索精準度高但答案相關性差，使用者反映「很接近但不完全正確」 檢測規則：若語意相似度 > 0.8 但使用者滿意度 < 60% 根本原因：查詢與文件嵌入向量針對不同語意空間進行最佳化 修正：切換至領域專用嵌入模型或實作含同義詞的查詢擴充
上下文窗口溢位
症狀：回應變得籠統，模型忽略特定檢索上下文，回答不一致 檢測規則：若上下文利用率 < 30% 且回應一般性分數 > 0.7 根本原因：過多不相關的區塊稀釋了相關資訊 修正：實作更嚴格的相關性閾值（>0.8）與動態上下文選擇
工具幻覺循環
症狀：代理虛構 API 呼叫、參考不存在的函式、無限重試迴圈 檢測規則：若工具呼叫成功率 < 50% 或迭代次數 > max_iterations * 0.8 根本原因：模型訓練時使用的工具架構與實作不符 修正：在代理系統提示中增加工具驗證層與明確的錯誤處理
嵌入漂移退化
症狀：檢索品質隨時間逐漸下降，季節性效能衰退 檢測規則：若月平均 retrieval@5 低於基線 10% 以上 根本原因：領域語言演進但嵌入模型維持不變 修正：實作嵌入模型重新訓練管線或切換至自適應嵌入
回應延遲潛增
症狀：P95 延遲逐漸增加，使用者抱怨回應緩慢 檢測規則：若連續 7 天的 P95 回應時間 > 基線 2 倍 根本原因：向量索引效能衰退、上下文大小膨脹或模型端點飽和 修正：實作索引最佳化排程、上下文修剪與多模型負載平衡
實戰範例
範例：客戶支援聊天機器人實作
初始需求：「建立一個能回答關於我們 500 頁產品文件問題的聊天機器人」
步驟 1：架構決策
- 文件數量：500 頁 → 使用 Pinecone 以獲得可擴展性
- 查詢類型：混合常見問題 + 故障排除 → 需要混合搜尋
- 延遲要求：< 3 秒 → 包含重新排序但進行最佳化
步驟 2：實作逐步解說
// 新手方式 - 會使用基本的相似度搜尋
const chunks = await vectorDb.query(queryEmbedding, { topK: 5 });
// 專家方式 - 考慮相關性閾值
const rawChunks = await vectorDb.query(queryEmbedding, {
topK: 20,
threshold: 0.7 // 確保最低相關性
});
// 專家加入新手會跳過的重新排序步驟
const reranked = await reranker.rank(query, rawChunks);
const finalChunks = reranked.slice(0, 3);
// 專家包含回退處理
if (finalChunks.length === 0) {
return await fallbackToGeneralSupport(query);
}
步驟 3：效能最佳化發現
- 初始 P95 延遲：4.2 秒（超過要求）
- 分析：60% 的時間花在重新排序
- 權衡決策：從 Cohere Rerank 切換至本地交叉編碼器
- 結果：P95 延遲 → 2.1 秒，滿意度小幅下降（92% → 89%）
- 專家見解：對於支援使用案例，速度 > 完美準確度
步驟 4：故障情境處理
- 發現 15% 的查詢關於文件中沒有的功能
- 新手：會回傳「我不知道」
- 專家：加入升級檢測並轉接給真人客服
最終架構：Pinecone + 本地重新排序 + 代理升級 = 89% 自動化率，P95 為 2.1 秒
品質閘道
- Retrieval@5 準確度 > 85%（在評估資料集上）
- 平均回應延遲（P95）< 3 秒
- 上下文利用率 > 60%（模型使用檢索到的資訊）
- 幻覺率 < 5%（回應未獲得檢索上下文支援）
- 使用者滿意度分數 > 80%（30 天滾動視窗）
- 每次查詢的 Token 成本低於預算閾值
- 系統正常運行時間 > 99.9%（排除計畫性維護）
- PII 檢測率 > 95%（回應中不包含個人資訊）
- 嵌入模型效能穩定（每月退化不超過 10%）
- 錯誤處理涵蓋所有故障模式並提供優雅降級
不適用範圍
請勿將此技能用於：
提示工程任務 → 改用 prompt-engineer
- 最佳化提示範本與指令
- A/B 測試提示變化
- 思維鏈提示設計
機器學習模型訓練/微調 → 改用 ml-engineer
- 訓練自訂嵌入模型
- 在領域資料上微調 LLM
- 模型架構研究
資料管線工程 → 改用 data-pipeline-engineer
- 訓練資料的 ETL 流程
- 資料驗證與清理工作流程
- 批次處理系統
基礎設施/DevOps → 改用 backend-architect
- Kubernetes 部署策略
- 資料庫最佳化與分片
- 負載平衡器配置
分析與監控設定 → 改用 chatbot-analytics
- 對話流程分析
- 使用者行為追蹤
- 效能儀表板建立
委派時機：
- 任務需要深度 ML 專業知識 →
ml-engineer - 重點在於對話設計 →
prompt-engineer - 需要基礎設施擴展 →
backend-architect - 需要使用分析 →
chatbot-analytics - 建構非 AI 功能 → 相關專家技能