我想喺自己嘅作品集網站上加一個細小嘅AI功能,可以回答訪客關於我背景同項目嘅問題,而唔使直接接入OpenAI或Anthropic嘅API密鑰,再處理各家唔同嘅計費方式。結果發現,OpenRouter係實現呢個目標最簡單嘅方法。
點解揀OpenRouter
OpenRouter將幾十間模型供應商統一收埋喺一個兼容OpenAI嘅API背後。我唔使為每間供應商分別搞唔同嘅SDK同API密鑰,而係只需要一個端點、一個API密鑰,以及一個隨時可以更換嘅模型字串。對於一個流量唔多嘅作品集聊天機械人嚟講,呢種靈活性比追求絕對最強嘅模型質素更重要。
揀一個平嘅模型
因為呢個機械人只需要回答關於我經歷同項目嘅有限範圍問題(而唔係開放式推理),所以我唔需要頂尖模型。我揀咗Gemini Flash同DeepSeek Chat呢類經濟型選項,OpenRouter用同其他模型完全一樣嘅請求格式暴露出嚟。對於一個喺作品集網站後台默默運行、按token計費嘅功能嚟講,同高端模型相比,成本差異相當可觀。
整體架構
聊天機械人跑喺作品集嘅Next.js前端後面,由一個輕量級後端服務負責實際嘅OpenRouter調用。流程好簡單:
- 前端將訪客嘅問題發送去後端接口
- 後端構建一個包含我背景/項目上下文嘅提示詞,發送畀OpenRouter,指定使用一個平嘅模型
- OpenRouter將請求路由去底層供應商,並返回一個標準嘅聊天補全回應
- 後端將答案轉發返去前端嘅聊天組件
因為OpenRouter完全照抄咗OpenAI嘅聊天補全格式,之後要切換模型(或者喺某間供應商出問題嘅時候切換去另一個模型做後備),只需要改吓設定,而唔使重寫代碼。
值得了解嘅幾點
- 速率限制同配額係按模型劃分嘅,唔同供應商都唔一樣,所以如果打算將某個模型用喺日常玩吓以外嘅場景,值得先去睇吓OpenRouter嘅模型頁面。
- 提示詞範圍好重要——因為用嘅係平嘅模型,我將系統提示詞寫得好精簡,上下文都只限於相關內容,而唔係每次都將成份履歷塞晒入去。
- 成本保持可預測,因為OpenRouter會顯示每個模型每次請求嘅價格,咁樣喺切換模型之前我就可以估算出每月嘅花費。
目前狀態:用得,但RAG部分仲未完成
呢個聊天機械人已經上線並能夠正常回應,而且喺一次對話入面能夠保留一定嘅記憶,但檢索增強生成(RAG)呢部分仲未做完。佢遠不如ChatGPT或Claude嗰種記憶能力咁敏銳——嗰啲系統背後有更成熟嘅上下文管理同檢索機制,而我呢個仲係相當基礎嘅實現。目前佢可以保留最近嘅對話上下文,但要穩定咁由更大嘅知識庫入面攞返正確嘅背景資訊,呢部分我仲需要好好完善。
總體嚟講,OpenRouter令我可以輕鬆咁將AI功能掛去一個副業項目上,唔使被綁死喺單一供應商度,亦唔使為一個經濟型模型就能搞掂嘅任務多花冤枉錢。RAG同記憶層係接下嚟要重點解決嘅部分。