如何在 WordPress 中实现 AI 搜索并保持可控

想象一下，你的机构正在为一家预约管理软件公司管理 WordPress 帮助中心。客户不断向客服咨询如何重新安排周期性预约。相关说明已经存在，但搜索“move my Friday bookings”却找不到这篇指南。

客户希望试用 AI 搜索。与其要求客户输入文章中完全一致的词语，不如让系统根据语义相似的问题匹配相应指南。第一版将返回现有文档的链接。

选择服务商会带来一个更棘手的问题：你今天推荐的服务，明年是否仍适合这个网站？你无法作出这样的承诺，而客户也不应在开始之前就需要你作出这种承诺。

你可以将原始指南继续保留在 WordPress 中，并构建集成，使更换搜索服务时无需重建帮助中心。

本文将介绍该项目从有限试用到扩大使用的全过程，解释配置中哪些部分需要由你掌控，以及托管服务如何让你的团队无论选择哪种 AI 工具、趋势或集成方式，都有余地进行调整。

你不能等到万事确定

下面是一种可能的情况。你的开发者刚开始比较各家服务，另一家供应商就宣布了新的搜索产品。客户转发公告并询问：“我们应该等等吗？”

与此同时，客服仍在发送同一篇文章链接。

在购买任何服务之前，你的机构可以调查当前搜索为何找不到这篇指南。帮助中心可能会将文章存储在自定义文章类型中，而当前搜索配置未将其纳入搜索范围；也可能是文章将周期性预约称为“series management”，而客户很少使用这一说法。

当然，这些问题需要不同的修复方法。开发者可以检查 WordPress 搜索是否包含帮助中心文章，编辑则可以补充客户使用的措辞，并明确哪些说明适用于当前软件版本。

近期的支持工单为你提供了可供测试的真实问题。客服团队已经知道每篇指南分别回答哪些问题，这很有帮助。在网站上试用这些问题，可以找出搜索失败之处，而不必猜测客户可能会输入什么。

语义搜索是改善搜索的另一种方式。它利用机器学习查找与查询含义相似的内容，即使措辞不同，也能找到相关结果。这有助于将“move my Friday bookings”这类表达与“reschedule recurring appointments”等其他表达关联起来。

底层文档仍然很重要。如果两篇指南介绍的是不同版本的预约软件，搜索服务就需要获取足够的信息来区分它们。

你可以先解决这些内容问题，同时暂缓采购决定。测试 AI 搜索时，你将拥有更整洁的资料库，以及一组可用于比较的问题。

WordPress 仍是内容的源头

取消搜索服务订阅时，不应从客户的 WordPress 网站中删除任何一篇指南。编辑仍可在 WordPress 中工作，搜索服务商则保存一份索引副本，而集成层会将内容发送给该服务商。

在规划替换方案时，这一区别很重要。你的机构需要能够根据原始文章重新建立搜索索引，而不依赖即将退出的服务商返回唯一副本。

在这个帮助中心中，自定义文章类型可以将指南与博客文章分开。自定义字段或分类法可以标明每篇指南所涵盖的预订软件版本。这些信息应与 WordPress 中的文章关联存放，以便编辑人员维护。

索引代码会将相关文本和元数据发送到搜索服务。它还会保留对 WordPress 文章 ID 的引用，使搜索结果能够指向正确的指南。

提供商的导出内容仍值得关注。您的团队可能会在服务商的仪表板中配置同义词或排名规则。在关闭账户之前，这些设置可能需要单独导出或记录。它们不应成为记录哪些指南涵盖当前软件版本的唯一位置。

编辑内容也需要同步到索引中。当编辑人员替换过时的说明时，集成需要更新或移除相应的已索引内容。如果不执行这一步，搜索仍会返回资源库中已不再包含的答案。

公开指南会让首次试用变得简单。如果客户之后添加仅限会员查看的文档，集成需要在显示受限结果或向答案生成模型发送摘录之前执行网站的访问规则。知道某人已登录，并不能确定其会员权限允许阅读哪些文章。

如何让提供商变更易于管理

搜索框可以保留在 WordPress 主题中，同时由插件处理提供商的 API。主题将查询提交给插件，插件发送请求，并将响应转换为网站所需的格式。

例如，插件可以将提供商的文档标识符映射回 WordPress 文章 ID。随后，主题使用相应的 WordPress 标题和固定链接显示匹配的指南。采用新的提供商需要对集成进行开发，而帮助中心的布局基本可以保持不变。

在估算相关工作量之前，还需要对“AI 搜索”作出更准确的定义。

在基于嵌入的系统中，模型会将文章文本转换为称为嵌入的数值表示。搜索索引会存储这些表示。系统将访问者的查询转换为兼容的表示，并搜索相关内容。

如果该功能包含这一步骤，大型语言模型随后可以使用检索到的摘录生成答案。返回相关文章链接并不需要生成答案。

您的代理机构可能会从托管搜索提供商处打包购买这些能力。另一种实现方式则可能使用相互独立的服务。无论采用哪种方式，开发者都需要确定拟议变更会影响其中哪一部分。

您通常可以替换生成答案的模型，同时保留现有搜索索引。更换嵌入模型通常意味着重新生成文档嵌入并重建索引。不同提供商之间的相关性得分也可能有所不同，因此开发者需要检查现有的筛选阈值是否仍能选出有用的结果。

需要注意的是 Andreessen Horowitz 2025 年对 100 位企业 CIO 开展的调查所汇编的最新数据。调查报告称，37% 的 CIO 至少使用五种模型，而上一次调查中的这一比例为 29%。对于这个假想的客户而言，一个服务可能已经足够，但实际需要考虑的是，后续替换会涉及哪些工作。

一个小插件就能实现这种分离，而不必把项目变成一个适用于世上所有供应商的框架。它的编码和配置方式应当让替换工作足够清晰，从而便于估算。

让实验范围易于管理

关于预约管理的 20 篇公开指南，足以为团队提供有用的初步测试材料。支持人员会整理客户提出的问题，并确定每道问题应由哪篇文章解答。

开发人员通过现有搜索和试用服务运行这些查询。正确的指南是否出现在前几条结果中？搜索能否区分修改一个预约与修改系列中所有未来预约？

测试还需要文档无法回答的问题。关于不受支持功能的查询，不应仅因措辞相似就把客户引向无关的说明。

如果试用包含生成的答案，则需要单独审核。答案可能引用正确的指南，却错误表述某个步骤。支持人员应检查客户按照该回复操作后能否完成任务。

四周的试用足以让客户决定是否继续使用该具体工具。预算也需要设置上限。如果提供商没有严格的支出上限，工具就需要设置用量限制，在约定的预算耗尽前停止新的付费请求。仅靠电子邮件提醒无法阻止扣费，因此最好提前做好规划。

Deloitte 的《2026 年企业人工智能状况》研究称，受访者中只有 25% 能将约 40% 的人工智能实验投入生产，因此值得了解该工具可能并不合适。

为工作负载变化做好准备

试用效果良好，客户希望在客户通讯中推广。几位支持同事在会议期间测试搜索，并不能告诉你该集成面对这类受众时的表现。

假设该 WordPress 插件会为每次搜索发出同步 API 请求。其 PHP 线程在等待外部响应期间会一直占用。同时进行多次缓慢搜索，可能使其他未缓存请求可用的资源减少。

因此，应在通讯发出前测试并发搜索。开发人员可以测量结果返回所需的时间，同时检查网站其余部分是否仍能保持响应。外部提供商的速率限制也应纳入测试。

使用成本也需要同等关注。一位访客可能会尝试多个查询。如果该功能会生成答案，发送给模型并由模型返回的文本量会影响基于 token 的费用。试用期间的请求记录比将访客数乘以单次搜索成本更能提供准确估算。

索引会在访客会话之外产生工作。更新一篇指南时，通常应只更新其索引内容，而不是为整个帮助中心重新生成嵌入。开发人员需要检查，当编辑点击“更新”时，所选插件或服务实际会执行什么操作。

扩展功能可以有选择地保留。如果客户发现链接有用，但很少阅读生成的摘要，客户可以保留语义搜索并关闭答案生成。将这些设置分开，可以让他们在不删除所重视改进的情况下，以具体方式降低成本。

重新考虑的理由

提供商停止支持插件所使用的 API，就意味着变更被提上了日程。新模型的发布可以等到有理由调查时再处理。

区分组件在这里很有帮助。如果你的机构选择并直接调用某个模型，就需要跟踪该模型的可用性。托管搜索服务可能会在内部处理模型变更，而你的团队只需关注其 API 通知和结果质量。

试用期间提出的问题可以组成一套小型回归测试集。开发者可以在服务提供商进行重大更新后，或针对拟议的替代方案运行这些测试。预期结果能让关于“更优搜索”的讨论具体得多。

对于定期预约查询，当前指南是否仍排在靠前位置？如果该功能会生成答案，它是否能保留修改单个预约与修改整个系列之间的区别？

比较时需要使用一致的源内容。用上个月的文章测试一家提供商，再用重写的指南测试另一家，几乎无法说明提供商本身的表现。测试记录应标明内容修订版本以及相关的模型或服务配置。

随着客户遇到缺口，支持工单可以添加新的查询。替代方案随后需要应对那些确实会给网站带来困扰的问题。

成本也可以成为再次评估的理由。只要答案保持准确，更便宜的模型可能更适合该客户。与其在客户自己的文档上的表现相比，通用基准测试分数能提供的证据价值较低。

选择能够为调整留有余地的托管方案

WordPress 预发布站点是一种很好的方式，可让开发者在客户继续使用线上搜索时安装替代工具。Kinsta 为这项工作提供预发布环境；需要更多资源的测试可使用 Premium Staging。

外部搜索设置也需要隔离。克隆 WordPress 时，可能会复制指向生产索引的插件设置。在预发布环境运行索引任务之前，开发者需要配置测试索引以及具有适当访问权限的凭据。否则，预发布测试可能会改变线上搜索结果。

Kinsta 的应用性能监控有助于调查集成中的 WordPress 端。启用 APM 后，开发者可以检查速度较慢的服务器端外部请求和数据库查询。浏览器端调用则需要浏览器诊断工具。APM 不会显示访问者浏览器发出的每个请求。

这些追踪信息可以确认 WordPress 的慢速搜索是否主要在等待提供商。增加托管容量无法缩短提供商的响应时间。

当测试发现 PHP 容量限制时，MyKinsta 可在现有套餐选项范围内调整 PHP 资源。更多 PHP 线程可以处理额外的并发请求，但将同一内存池分配给更多线程，会减少每个线程可用的内存。性能比较还需要预发布资源和缓存设置合理反映生产环境。

当你的机构在更多网站上开展试用时，Kinsta API 端点可让内部工具获取环境详情或创建预发布环境。团队可以自动完成准备工作，同时不向搜索提供商授予对托管账户的控制权。

你的机构仍需决定替代方案的表现是否足以发布。托管环境提供了一个场所来测试这项决定并调查结果。

提案中的各项承诺

“添加 AI 搜索”留有太多分歧空间。你的方案可能涵盖相关 articles 的链接，而客户期望的却是能写出完整答案的聊天机器人。

方案应描述客户实际看到的内容。对于这个项目，首期承诺可以涵盖对 20 份公开指南的语义搜索，而生成式答案则另行决定。

提出几个问题，有助于明确其余边界：

• 这次试用要解决什么问题？ 客户找不到最新的预约管理说明。双方商定的测试查询反映了这些支持请求。
• 哪些内容仍由客户掌控？ WordPress 保留原有指南及其元数据。代理机构会记录仅存在于服务商控制面板中的搜索设置。
• 哪些内容依赖这项服务？ 方案会明确帮助中心的搜索集成，以及它调用的任何模型 API。网站的其他区域继续使用现有的搜索。
• 客户如何终止这项试验？ 一项设置可恢复现有搜索。停用流程还会停止定时索引任务，并关闭不再需要的付费服务。
• 怎样才能推广到更大范围？ 客户会就什么算相关结果、访客最多可以等待多久达成一致。试用期间的使用情况可用于估算运行成本。

更大范围的推广需要单独预留预算，用于索引其余内容库并测试高负载下的表现。将这项工作单独估算，可以让客户在作出承诺前先评估试用结果。

方案还可以明确由谁在四周结束时审查结果。否则，下一次订阅续费可能会默认决定后续方案。

为下一步决策留出空间

这家预约软件客户可以借此了解语义搜索是否有助于客户找到预约指南，而无须现在就选定未来五年的服务提供商。

原有 articles 仍保留在 WordPress 中。如果试用结果不尽如人意，客户可以保留编辑方面的改进，并恢复现有搜索。如果试用成功，你的代理机构就有了支持扩大推广范围的依据。

未来更换服务提供商仍需要投入工作。必须有人调整 API 集成并测试结果。根据变更情况，重建索引可能耗时并产生使用费用。将这些任务与网站其他部分分开，会更容易规划。

这是值得向客户提供的一种控制方式。你可以说明他们今天承诺了什么，以及以后选择其他方案需要付出哪些工作。

Kinsta 的托管 WordPress 主机为你的团队提供预发布环境和性能工具，以支持这些决策。你的代理机构现在就可以试用一项实用的 AI 功能，同时随着客户需求变化，保留清晰的调整路径。

文章《如何在 WordPress 中实现 AI 搜索并保持掌控》最初发布于 Kinsta®。