香港AI項目為何交付失敗：三個工程師視角才能識別的採購陷阱

不是模型不夠好，不是預算不足。香港AI項目失敗最常見的三個原因來自工程師視角——是採購決策層難以在提案階段察覺，但能夠提前避免的結構性問題。本文不是要勸退讀者部署AI，而是幫助您在簽約前問到正確的問題。

AI項目管理採購決策香港企業工程師視角

前提：失敗的定義

本文所指的「失敗」不是系統當機或完全無法使用。大多數AI項目的失敗是更隱性的：系統上線了，但無人實際使用；或在運行三個月後出現問題，發現修復成本極高；或業務擴展時發現系統架構根本無法支撐。

這類失敗的共同特點是：在提案審批階段完全看不出來，但在工程師進行設計評審時是可以識別的結構性問題。

示範階段，供應商展示系統能準確回答問題。採購方審批通過。上線後，系統開始出現「自信地回答錯誤」的情況——對知識庫範圍以外的問題，系統生成聽起來合理但事實有誤的答案。

這不是模型問題，而是系統設計問題。一個生產級RAG系統需要明確處理「置信邊界」：當檢索結果的相關性低於某個閾值時，系統應回答「在現有資料中找不到足夠相關的資訊」，而非強行生成一個回答。

在HKSoka及客戶交付系統中，置信邊界是設計的組成部分，而非事後加入的修補。這個設計在token成本上有代價（需要額外的相關性評分步驟），但在可靠性上是必要的。

簽約前詢問：「當系統知識庫中找不到相關資訊時，系統會如何回應？請展示一個您的系統無法回答的問題。」

AI系統的運營成本主要來自LLM API調用。示範環境通常以小數據量、短對話、低頻率進行測試。生產環境則是真實用戶、完整文件、高頻調用——兩者成本差距可達十倍以上。

更具體的問題在於context window管理。一個未做好context管理的系統，每次對話都將完整歷史記錄發送給LLM——對話越長，成本越高，速度越慢。

HKSoka系統的實測數據：透過token-based context window管理（取代message-count截斷）、對話摘要pipeline與prompt caching，短對話每輪成本下降54%，長對話下降80至90%。這不是理論優化，而是生產系統的實際測量數字。

此類優化需要在架構設計階段完成，而非上線後補救——因為上線後修改context管理邏輯，需要影響整個對話歷史的處理方式。

簽約前詢問：「請提供成本估算模型：基於多少用戶、平均對話輪數、文件量。若用戶量增加三倍，成本增加多少？系統採用了哪些成本控制措施？」

OpenAI、Anthropic、Google的API均有服務中斷記錄。若您的AI系統完全依賴單一供應商，服務中斷即等同於系統中斷。

這個風險在許多採購文件中完全未見提及，原因是供應商習慣上只展示正常運行的系統。然而生產環境需要考慮故障場景。

在為某香港航運公司交付的系統中，multi-LLM fallback chain是基礎設計的一部分：主力供應商中斷時，系統自動切換至備用供應商，對用戶透明。具體哪個供應商擔任主力，是依據翻譯一致性、幻覺率、輸出格式三個維度的實測評分決定，而非依據品牌。

另一個隱性依賴：若系統深度依賴某一供應商的特有功能（例如特有的API格式），未來該供應商調整定價或政策，遷移成本將極高。

簽約前詢問：「若您使用的LLM供應商今日服務中斷，系統如何應對？是否有fallback機制？系統是否深度依賴某個供應商的非標準功能？」

許多AI系統以LangChain或LlamaIndex等abstraction framework構建。這些framework加快了開發速度，但引入了一個隱性問題：framework本身有版本、有bug、有功能棄用（deprecation）。系統間接依賴一個無法控制的第三方代碼庫。

以native LLM API直接構建的系統，調用鏈更短，延遲更低，調試更直接，對framework版本變動免疫。代價是開發者需要自行實現orchestration邏輯，但這個邏輯是可控且可審計的。

這不是「native API必然優於framework」的絕對論斷，而是要提醒：詢問「您用什麼framework構建」之後，同時詢問「若此framework被棄用，您的系統會受到什麼影響」。

本文所述的問題有一個共同特點：是工程師在設計評審時會考量的問題，但在銷售提案中通常不會出現。

對應的採購策略是：在正式提案之前，先進行一次技術評審——以工程師視角評估供應商的設計決策，而非以銷售材料作為評估依據。這個評審的成本遠低於上線後發現問題的修復成本。

希望在簽約前進行獨立技術評審？提供獨立AI項目技術評估——以工程師視角檢視供應商的架構設計，而非供應商委託的合規審計。

Levi係駐香港嘅獨立AI工程師，為香港推動AI數碼轉型嘅中小企構建生產級LLM應用、RAG pipeline及文件智能系統。