AI 睇樓不是夢：PropTech + RAG 實戰拆解

你上次喺香港任何一個地產平台搵樓，有冇試過輸入「 Budget 一萬蚊、想近地鐵、最好新裝修、唔要納米樓」，然後得到七百幾個不相關嘅 results？有。幾乎人人都試過。香港地產平台嘅搜尋體驗，二十年嚟進步嘅幅度大概係——由一個 checkbox 變成三個 checkbox。關鍵字搜尋、filter 疊 filter、睇到眼花嘅列表，然後每一個單位你要自己開、自己睇、自己判斷是否符合。成個流程仲停留喺「俾工具你，你自己搞掂」嘅思維。但問題係：用戶想要嘅唔係更多 filter，而係一個真正明白佢需要嘅 assistant。

七千個 Test 煉成嘅 AI Agent

我哋做呢個 AI Real Estate Assistant 嗰陣，定咗一個好「唔 AI 嘅」原則：唔可以用「AI 有時會錯」做藉口。地產係高決策密度嘅場景——一個錯嘅 recommendation 可以浪費用戶幾個星期。所以我哋做咗一個傳統 software engineering 先會做嘅決定：寫 test。唔係幾個，係七千幾個。

七千個 test 聽落好瘋狂，尤其係喺一個 LLM-based 嘅 product 入面。但我哋嘅邏輯好簡單：每一個 test 對應一個真實用戶會遇到嘅 edge case——例如「用戶話『近地鐵』但冇講邊條線」、「用戶 budget 係兩萬但佢想要嘅地區平均樓價係兩萬五」、「用戶話『三房』但實際係想搵『兩房+工人房』」。每一個呢啲 case，我哋都寫成 automated test，每次改 model prompt、改 retrieval strategy、改 ranking logic 嘅時候，成個 suite 行一次。

呢個做法俾咗我哋一樣好珍貴嘅嘢：信心。當你改完一個 component 之後，七千個 test 喺五分鐘內同你講有冇嘢炒咗，你就可以好放心咁繼續 iterate。LLM 嘅 non-determinism 唔係藉口——只要你將 expected behaviour 寫清楚，test 自然捉到你唔想見到嘅 drift。

六個 LLM 點樣分工合作

講到 architecture，我哋用咗六個唔同嘅 LLM 去處理唔同嘅任務。呢個決定唔係因為「多就勁」，而係我哋發現無一個 model 喺所有維度上都係最好。

第一個 LLM 負責 query understanding——用戶輸入一句廣東話口語「一萬蚊樓下、近地鐵、最好有會所」，佢要拆成 structured 嘅 search criteria。第二個做 hybrid search 嘅 ranking fusion——將 keyword search、vector search 同 knowledge graph search 嘅結果做 weighted merging。第三個負責 context augmentation——將搜到嘅單位資料加上周邊資訊（校網、交通、社區設施）。第四個做 constraint satisfaction check——確保 recommendation 真係符合用戶所有條件，有 trade-off 嘅要 highlight 俾用戶知。第五個負責 multi-turn conversation memory——記住用戶之前講過啲咩 preferences。第六個做 final response generation——用流暢嘅廣東話同用戶解釋點解推薦呢啲單位。

呢個 modular approach 有個好重要嘅好處：你可以獨立 upgrade 每一個 component。當有新 model 出，你只需要換走對應果個，而唔係成個 monolithic agent 重新 train 過。混合搜索嘅部份我哋用咗 reciprocal rank fusion 嚟 combine BM25、dense vector embeddings 同 domain-specific knowledge graph 嘅 scores，結果比任何單一 search method 好 30% 以上。

RAG 喺地產場景嘅真正挑戰

PropTech 用 RAG，表面睇好直接：document 係樓盤 listing，query 係用戶需求，retrieve + generate 就搞掂。但現實係，每一個環節都有地產-specific 嘅陷阱。

第一個陷阱係「多模態 mismatch」。Listing 嘅重要資訊通常唔係喺文字 description，而係喺 floor plan、video walkthrough、甚至係 drone shot。文字 RAG 根本 handle 唔到。我哋嘅解決方案係 pre-processing 階段用 vision model 自動 caption 每一張相片同片，將 visual features 轉做 structured text 再 feed 入 vector store。呢樣嘢令 recall 提升咗接近一倍，尤其係用戶問「有冇梗廚」、「有冇窗台」呢類視覺主導嘅問題。

第二個陷阱係「ranking 唔可以靠 relevance alone」。傳統 RAG 嘅 similarity search 會俾返「最似」嘅結果，但地產嘅 ranking 要考慮價格合理性、供應稀缺性、甚至係用戶嘅 hidden preference（例如用戶冇講但明顯傾向某個地區）。我哋用一個 lightweight 嘅 learning-to-rank layer，用之前用戶嘅 interaction data 去 calibrate 個 ranking，而唔係就咁 cosine similarity 排。

第三個陷阱係「freshness」。一個 listing 今日仲 available，聽日可能就 sold。我哋設計咗一個 incremental ingestion pipeline，每十五分鐘 sync 一次最新 listing 狀態，stale document 會自動被排除喺 retrieval 之外。token 成本唔係最貴嘅嘢——俾一個已賣嘅 unit 俾用戶睇中，嗰個 user experience 成本先係。

對創業者同開發者嘅實戰建議

如果你打算喺呢個領域做嘢，我有三個建議。

第一，唔好迷信 end-to-end LLM。 Modular agent architecture 俾你嘅 control 同 debuggability 係 monolithic prompt engineering 俾唔到嘅。當你 production 出問題嘅時候，你可以 pinpoint 係邊個 component 出事，而唔係成個 black box 重新 tune。

第二，test 係你對抗 LLM randomness 嘅唯一武器。唔好聽人講「AI 產品唔使寫 test」。愈係 AI product，愈要寫 test，因為你嘅 system behaviour 本身就比 traditional software 更難預測。每一條 prompt change、每一個 model update，都應該有 automated validation。

第三，domain knowledge 係你嘅 moat。任何用 ChatGPT API 嘅人都可以整到一個「地產 chatbot」，但要整到一個真正明香港人需要、知道港島東同九龍東嘅 lifestyle 分別、明白「唔要納米樓」背後係實用面積 300 呎以上嘅 assistant，呢啲 domain knowledge 先係真正嘅護城河。唔好淨係做 RAG wrapper——要 invest 喺 domain-specific data 同 logic 上面。

香港嘅 PropTech 仲有好大空間，尤其係 agent experience 呢一層。當大部分 platform 仲俾緊 filter 俾你慢慢㩒嘅時候，early mover 用 AI 做真正嘅 intelligent assistant，呢個 window 唔會開好耐。