理解情境
唔只搵相似 FAQ，而係先拆解使用者真正經營情況同已知 facts。
PROJECT / GOVERNMENT AI × KNOWLEDGE MANAGEMENT
LIC記LIC-KEE · v1.0
由「搵相似 FAQ」行前一步：先理解個案，再決定要答、要問、要查證，定係轉人工／其他部門。
一個以 FEHD 官方牌照資料為基礎嘅 AI Licensing Assistant Prototype。RAG、多輪對話、Policy Registry、官方牌照名稱白名單、Evidence / Citation Validation 同 Human Escalation 都放入同一套可版本化系統。
3,089ACTIVE KB RECORDS
1,024EMBEDDING DIM
3MAX CLARIFICATIONS
v1.0FROZEN RELEASE
情境理解，而唔係見字就配答案示意對話 · 非實際即時回應
我想頂手一間地舖做咖啡輕食，20 個位，賣預製蛋糕同意粉，冇明火，大牌定細牌？
關鍵資料仲差一樣：
你啲意粉實際會點樣烹調？例如只翻熱／水煮，定係會煎炒？呢個 facts 會直接影響應該再查邊一條牌照路線。
你啲意粉實際會點樣烹調？例如只翻熱／水煮，定係會煎炒？呢個 facts 會直接影響應該再查邊一條牌照路線。
唔自行推斷 cooking method只問 decisive fact再按 evidence 判斷
01 / WHY IT IS DIFFERENT
真正優點，唔係「識答多啲」。
而係用一套受控流程，將自然語言、官方資料、政策邊界同人工判斷接埋一齊。
只問關鍵問題
資料不足時，唔亂估；先找真正會改變結論嘅 decisive fact。
多輪重新判斷
新 facts 會更新 canonical state，必要時推翻上一輪嘅 route。
官方 Evidence
回答建立喺官方資料檢索之上，而唔係只靠模型記憶。
部門邊界
涉及 LandsD、PlanD、FSD、EPD 等範圍時，唔代其他部門作 case decision。
Human Escalation
知道幾時應該停；無法可靠判定時，轉人工而唔係硬答。
02 / FAQ BOT VS LIC-KEE
最大分別唔係模型大細，而係工作方式。
FAQ / navigation 對標準問題仍然非常有價值；LIC-KEE 探索嘅係複雜個案再上一層。
「你問緊邊一條現成問題？」
- 收到問題
- 比對關鍵字／語意
- 找最相似 FAQ
- 顯示答案或相關連結
「你實際個情況係咩？」
- 拆解 case facts
- 找 decisive fact
- 需要先問一條關鍵問題
- 檢索官方 evidence
- 再答、分流或 Human Escalation
CASE EXAMPLE
「20 座位、咖啡、蛋糕、意粉、冇明火」點解仲未可以直接判大牌定細牌？
真正 decisive fact實際 cooking method
「意粉」唔等於「炒製」，「冇明火」亦唔等於「簡單烹調」。所以系統應該先確認，而唔係替使用者補完個案。
03 / TECHNOLOGY
用咗咩技術？
核心唔係單一 LLM，而係 Conversation、Policy、Knowledge、Evidence 同 Validation 幾層一齊工作。
FRONTENDReact + Vite
BACKENDFastAPI
VECTOR DBChroma
EMBEDDINGQwen3 0.6B
POLICYRegistry + Whitelist
ANSWER LLMOpenRouter / Qwen
CORE PRINCIPLELLM understands and proposes.
LLM understands and proposes.
Code validates and executes.
另一個核心原則KB ≠ LLM
Knowledge Base 係長期可搬資產；回答模型係 replaceable component。換 model 唔需要重建整個 KB。
04 / GO DEEPER
想再深入，可以分開睇。
首頁只講價值同定位；詳細問題、架構同 Proposal 拆去獨立頁，避免一次塞晒全部資料。