自然語言查詢網站的新技術NLWeb，真人與AI代理都能用

有時候，我們很清楚自己需要尋找什麼資訊，更確信這則資訊存在於網站上，卻遲遲找不到。「需要170公分女生穿起來不會卡膝蓋的七分褲」、「找出學區中，有後院和泳池且附近有公園的建案」，這些需求用自然語言不難理解。不過，利用常見條件過濾器或傳統語意相似性機制來搜尋，時常會查不到準確、完整的結果。

微軟認為，要解決這種挑戰，得打造一種易用的技術，讓真人可以用自然語言和網站對話，不只能提升真人上網體驗。就連AI代理接受自然語言指令，到網路上尋找解方並執行任務時，也能大大受益，進而使網路世界更接近Open Agentic Web的願景。

微軟找來攻略這個挑戰的專家是R. V. Guha，他是RSS和RDF網路標準的創建人，更曾領銜打造Google自訂搜尋功能。結合搜尋技術和AI技術，他們推出開源框架NLWeb，來降低網站主打造自然語言溝通介面的技術門檻，更內建MCP支援，讓網站主打造成自家網站的MCP伺服器，可供AI代理查詢。微軟希望，這項技術成為未來網站主用來呈現內容給AI代理的共同語言。

用LLM處理搜尋請求和資料檢索，為網站輕鬆打造語意搜尋機制

NLWeb是一個框架，支援網站資料索引、自然語言查詢處理、LLM呼叫、向量資料庫呼叫，及站內搜尋處理等作業。導入此框架後，等於設置好一個站內自然語言搜尋後端機制。

NLWeb框架中提供的工具，可以用來讀取網站RSS Feed、Schema.org資料，或者其他常見結構化元資料，為網站內容建立索引，儲存到向量資料庫。建立索引時，開發者也可以匯入更多資料，如網站其它後端資料庫，來進一步增加檢索準確性。

當用戶端送出查詢請求後，NLWeb會比對請求與網站內容的相關性、將搜尋內容拆解成不同個子查詢指令、記憶所需內容，並從向量資料庫中查詢出候選項目。

接著，LLM會評分回傳結果的相關性，並依照相關性高低排序結果。如果使用者要求LLM進一步處理資料，例如進行摘要、再搜尋等，會在此階段進行，否則，會依照使用者要求格式回應搜尋結果。

R. V. Guha強調，相比傳統RAG做法，可能產生幻覺，NLWeb框架下的搜尋做法，所有回傳結果都有網站資料的索引ID。也就是說，查到的資料即使關聯性不高，也必然是真實存在的資料，AI不會捏造出網站內容。

NLWeb框架可以根據網站主需求，部署在地端或雲端。框架也內建許多控制項可以調整，例如負責排序和分析查詢內容的LLM、負責建立索引的嵌入模型、儲存索引的向量資料庫、搜尋結果排名邏輯，以及許多前後端設計選擇。

R. V. Guha強調，網站主導入NLWeb框架後，可以自由利用此技術，來支援適合網站內容性質和商業模式的網站體驗，未必只是單純站內搜尋。例如，用來支援商品個人化推薦、旅遊規畫、飯店訂房等。NLWeb也內建MCP支援，除了打造針對真人使用者的網站體驗，開發者還可以用來打造MCP伺服器，供AI代理更有效率的查詢自家網站資料。

圖為NLWeb處理查詢請求的流程。使用者發出對話式搜尋指令（1）後，會經過簡單的檢查，決定是否需要呼叫LLM檢查網站內容與搜尋指令的相關性、拆解搜尋內容、記憶相關內容（2a），或直接呼叫資料庫查詢（2b）。接著，查詢指令會送到資料庫來取得候選項目（3），由LLM依照相關性分數高低來排序（4）。LLM可能還會進一步處理資料，例如寫生成摘要（4a）。最後，結果會以指定的格式回傳給使用者（5）。備註：微軟Github上原圖沒有3*箭頭，iThome根據微軟於Github的文字說明及程式碼，為其補上。圖片來源／微軟、iThome整理

NLWeb應用先行者案例：TripAdvisor

國際旅遊評論網站TripAdvisor是導入NLWeb框架的先行者，目的是，使用者用簡單一句話查詢，來取代一系列搜尋操作。例如：「父親節想在西雅圖吃晚餐，要有好酒、靠近派克市場。」這樣的敘述過去需要手動選擇「地點」、「主題」、「酒單」等多個欄位。利用NLWeb帶來的語意搜尋功能，則能快速查到所需內容。

TripAdvisor負責實驗NLWeb的團隊表示，自家資料與系統原本就有搜尋優化，導入NLWeb過程相當順利。他們只需串接NLWeb到自家前端搜尋介面，以及後端Qdrant向量資料庫，幾乎不須做出其他改動。目前，他們用NLWeb來支援既有搜尋功能，未來則計畫整合到網站上既有的旅遊規畫工具中。

該團隊還提到，導入NLWeb的好處是能更有效運用自家資料，來增加自家內容曝光數。他們還希望，未來不需要過濾條件搜尋功能後，工程師可以減少自己手動新增、更新等維護資料標籤的繁複作業。

NLWeb應用可能固然多，限制與代價仍應充分了解

微軟設計NLWeb時，目標使用者是網站主，如TripAdvisor、Shopify等。他們期望，網站主可以用NLWeb的語意搜尋功能，打造出讓真人使用者及AI Agent都更好查找資料的網站功能。

NLWeb應用還不限於此。R. V. Guha提到，甚至可以利用NLWeb一口氣整合多個網站作為資料來源，來進行跨站搜尋。除此之外，由於NLWeb只需要網站RSS Feed即能建立搜尋索引，第三方使用者也可以用來打造網站爬蟲、搜尋、分析等不同功能，來自行使用，或進一步包裝成商業產品。

網站主如何評估，該不該導入NLWeb技術？

資深Elasticsearch專業講師吳楨文（喬叔）根據多年搜尋系統實戰經驗評論，從頭打造語意搜尋機制不易，NLWeb將所需技術整合成一套易用性高的解決方案，確實有助於開發者快速導入，打造具有一定可用性的網站功能。

不只如此，微軟參與NLWeb專案，意味著未來旗下產品可能高度支援，而NLWeb內建支援MCP的特性，更代表此框架能快速與其它支援MCP的工具搭配運用。

吳楨文認為，一旦生態圈豐富，技術支援和應用可能性會隨之增加。搭配NLWeb開源特性，還能期待有更多開發者一同改善框架本身。這些都是吸引開發者的誘因。

不過，吳楨文指出，市面上有許多具備與NLWeb類似的開源軟體或商用軟體，例如Google的Vertex AI Search，客製化功能相當豐富，也需要網站主具備更高的開發能力。開源的搜尋和網站索引技術也有Firecrawl、Elasticsearch等，開發彈性極高。NLWeb只是網站主用來打造語意搜尋機制的其中一種選項，導入與否，仍應充分了解不同選項帶來的限制。

例如，NLWeb建立索引的一大資料來源是RSS資訊及網站內容的元數據。當使用者查找網站內容性質屬於「項目清單」時，例如商品、餐點、景點、電影、食譜等，NLWeb搜尋品質才會最高。反之，若網站內容不容易用結構化資料描述，則需要更多預先處理，才能提升搜尋品質。

再來，NLWeb目前沒有自動更新搜尋索引功能。若網站內容具備高時效性，或內容頻繁更新，網站主即需要時常建立搜尋索引，否則會降低使用者網站體驗和AI代理資料蒐集的精確度。

NLWeb也可能帶來難以負擔的網站營運成本。NLWeb搜尋機制設計下，處理1次使用者查詢需求，有可能會對LLM發出高達50次呼叫。若網站處理的搜尋請求次數多、複雜度高，LLM使用費會快速累積。

不只如此，NLWeb只提供語意搜尋後端機制。如何用來設計前端體驗、整合進既有網站服務，或串接其它網站前後端系統，都得由開發者自行處理開發、維運及成本控管。吳楨文提醒網站主，應評估NLWeb打造的新功能，能否支援網站本身商業模式，帶來超出營運成本的效益。