Lychee-Rerank与微信小程序结合打造移动端智能文档搜索工具你有没有遇到过这种情况在公司内部的小程序里想查个产品手册或者报销制度输入关键词后搜出来的结果要么完全不沾边要么一大堆文件让你自己翻。明明知道资料就在系统里却怎么也找不到这种感觉确实挺让人着急的。传统的搜索很多时候只是机械地匹配关键词。比如你搜“年假申请”它可能把标题里带“申请”两个字的所有文件都扔给你而真正讲“年假”具体怎么休、需要什么流程的那个PDF可能因为标题是“员工休假管理办法”而被排到了后面。这种搜索体验在手机端尤其让人头疼。最近我们尝试把Lychee-Rerank这个专门做语义重排序的模型和微信小程序结合了起来做了一个移动端的智能文档搜索工具。简单来说就是让小程序不仅能“听到”你输入的字还能“理解”你真正想找什么然后把最相关的结果优先推给你。这篇文章我就来聊聊我们是怎么做的以及在这个过程中遇到的一些有意思的问题和解决办法。1. 为什么要在小程序里做智能搜索在做技术方案之前我们得先想清楚为什么非得在小程序里折腾这个直接用网页版或者App不行吗首先微信小程序有个很大的优势就是“即用即走”不用下载安装。对于企业内部工具来说推广成本低员工接受度高。大家打开微信就能用非常方便。其次很多企业的内部资料比如产品手册、规章制度、培训材料更新频率其实不低。如果每次更新都要员工去下载新版本的App或者记住某个复杂的网址体验就打了折扣。但小程序自带的搜索能力通常比较基础。它更多依赖于文件标题、标签或者全文的关键词匹配。这就导致了一个问题语义鸿沟。用户想的和系统“理解”的经常对不上。举个例子行政发了个通知标题是《关于优化2024年度差旅报销流程的补充说明》。员工可能记不住这么长的标题他可能只记得“出差报销有新规定了”于是他在小程序里搜“出差报销新规”。传统的搜索很可能因为匹配不上“优化”、“流程”、“补充说明”这些词而把这个最重要的通知给漏掉或者排到很后面。Lychee-Rerank这类模型干的就是“理解”的活儿。它不只看字面是否匹配而是会计算你的查询语句和每一个候选文档在语义上的相似度。哪怕字面上一个词都对不上只要意思相关它也能给找出来并且排到前面。这就是我们想在小程序里实现的核心价值让搜索变得更聪明、更懂你。2. 整体架构云函数是关键桥梁把一个大模型直接塞进微信小程序是不现实的。一来小程序包大小有限制二来模型推理对计算资源要求高手机端跑起来体验会很差。所以我们的核心思路是前端负责交互和展示复杂的模型推理放在云端。整个架构可以分成三块来看第一块微信小程序前端。这就是用户直接接触的界面。它的任务很简单提供一个搜索框让用户输入问题然后把问题发送到云端最后把云端返回的、已经排好序的搜索结果清晰友好地展示出来。这里的设计要足够轻量、响应快。第二块也是最重要的一块云函数。我们选择把Lychee-Rerank模型部署成一个独立的、可通过网络调用的服务也就是云函数。小程序前端不直接和模型打交道它只和这个云函数通信。云函数收到前端的搜索请求后会做几件事先去企业的文档数据库比如OSS对象存储、或者公司的知识库系统里根据关键词进行一次初步的“粗筛”得到一批可能相关的候选文档列表和它们的摘要或片段。调用Lychee-Rerank模型将用户的查询语句和这批候选文档一一对比计算出一个相关度分数。根据这个分数对候选文档列表进行重新排序。把排序后的结果包括文档标题、最相关的片段、链接等打包返回给小程序前端。第三块后台文档存储与索引。这部分是企业原有的基础设施可能是一个文件服务器也可能是一个Elasticsearch搜索集群。云函数需要有能力从这里快速获取到候选文档。这样做的好处很明显。模型部署和运维的复杂性被隔离在云端小程序开发者无需关心计算压力由云端承担保证了手机端的流畅体验而且这个云函数可以同时服务多个小程序甚至其他应用复用性很高。3. 前端交互简单背后有心思小程序前端的界面看起来简单就是一个搜索框加一个结果列表但设计上有些细节值得琢磨。首先搜索框的交互要友好。我们加入了搜索历史记录和热门搜索建议减少用户重复输入。在用户输入时可以考虑做一个“搜索联想”但这需要后端有相应的联想词服务支持我们第一期没有做而是把重点放在了结果页。其次结果列表的展示至关重要。既然我们用了重排序模型找到了最相关的结果就要把“相关性”直观地体现给用户。我们设计了这样的结果卡片文档标题突出显示。相关性摘要片段这是重头戏。我们让云函数不仅返回排序结果还返回模型认为与查询最相关的那个文本片段通常是几句话。我们会将这个片段高亮显示在结果中用户一眼就能看到“为什么这个文档被推荐给我”。比如搜索“年假”摘要片段可能高亮显示“员工累计工作满1年后可享受5天带薪年假”这句话。元信息文档类型PDF/DOC、更新时间、来源部门等。操作按钮查看详情、下载等。为了提升体验我们实现了无限滚动而不是传统的分页更适合移动端浏览。同时在用户点击搜索到结果展示出来之间必须有清晰的加载状态提示比如一个骨架屏让用户知道系统正在努力“思考”而不是卡住了。4. 数据传输与安全不能忽视的环节小程序和云函数之间的通信安全是必须考虑的问题。我们主要做了以下几件事1. 通信加密微信小程序要求必须使用HTTPS协议这为基础通信提供了加密保障防止数据在传输过程中被窃听。2. 身份认证与授权不是谁都能调用我们的搜索云函数。我们利用微信小程序的登录能力获取用户的openid或unionid。云函数在接到请求时会验证这个身份标识并判断该用户是否有权限搜索企业内部的文档。同时我们为云函数配置了访问密钥小程序端在请求时需要携带由密钥生成的签名防止接口被恶意调用。3. 敏感信息脱敏云函数返回的文档摘要片段在返回前会做一次简单的检查避免将某些敏感的账号、身份证号等信息直接返回前端。更复杂的内容过滤可以在文档入库阶段完成。4. 请求频率限制为了防止恶意爬虫或者程序故障导致的洪水攻击云函数服务端对来自同一用户或同一IP的请求频率做了限制比如每分钟最多30次搜索。这既保护了后端服务也避免了不必要的模型调用成本。5. 性能优化让“智能”不卡顿智能搜索听起来好但如果搜一次要等十秒钟用户肯定无法接受。性能优化贯穿了我们整个项目。云端优化候选集大小控制这是影响性能的最大因素。Lychee-Rerank需要对每个候选文档进行计算。如果第一步“粗筛”返回了1000个文档那重排序就会很慢。我们通过优化粗筛的关键词索引将候选集控制在20-50个高质量文档内在召回率和速度之间取得平衡。模型服务化与批处理我们将Lychee-Rerank模型封装成高性能的推理服务比如用Triton Inference Server并支持批处理。云函数可以一次性将用户查询和一批候选文档发送给推理服务而不是逐个查询这大大减少了网络开销和计算延迟。缓存策略对于热门、常见的搜索词如“报销”、“请假”其排序结果在一定时间内比如5分钟变化不大。我们可以在云函数层或专门的缓存服务如Redis中缓存这些查询的结果下次相同查询直接返回极大提升响应速度。前端优化防抖搜索用户在搜索框输入时每敲一个字就发起搜索是不现实的。我们设置了防抖比如用户停止输入300毫秒后才真正发起搜索请求避免无效的频繁调用。请求超时与重试设置合理的请求超时时间如5秒并设计友好的超时提示界面。对于因网络波动导致的失败可以提供手动重试按钮。本地缓存将用户的搜索历史、以及可能重复查看的搜索结果如第一条在小程序本地存储中做短暂缓存提升二次访问的体验。6. 实际效果与思考我们把这个工具在一个几百人的团队内部做了试点。上线后最直观的反馈是“现在好找多了”。以前需要翻好几页才能找到的制度文件现在经常排在第一个。特别是对于一些口语化、不规范的搜索词智能搜索的优势非常明显。当然过程中也发现了一些可以继续改进的地方。比如有些非常专业的术语缩写模型可能不太理解需要我们在知识库构建时补充同义词词典。另外当文档库非常庞大时如何设计更高效的“粗筛”策略既能保证召回率又不给重排序模型太大压力也是一个需要持续调优的点。从技术角度看把Lychee-Rerank通过云函数的方式赋能微信小程序这个模式是跑通了。它相当于给小程序装上了一个“语义理解”的外挂用相对低的成本显著提升了移动端信息检索的体验。这套架构其实也不局限于企业内部文档稍微调整一下完全可以用于电商商品搜索、内容社区问答、教育题库检索等各种需要“更懂你”的搜索场景。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。