微软
有时候，我们很清楚自己需要寻找什么资讯，更确信这则资讯存在于网站上，却迟迟找不到。「需要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打造的新功能，能否支援网站本身商业模式，带来超出营运成本的效益。