[AI创意笔记 01] SlideOn：用两项成本预算，调好一个更小的搜索模型

AI创意笔记探索新兴AI模型与工具背后的思路，以及它们在实际应用中的可能性。

你记得有份文档解释如何取消订单。搜索框却只认识“取消”这个词，而文档偏偏把同一个流程叫作“撤回”。资料库即使存着正确答案，也可能很难使用。

LightOn于2026年10月19日发布SlideOn和mSlideOn，用于检索相关文档。SlideOn面向英语，mSlideOn则把这一方法扩展到多语言文本、长文档和代码。它们特别值得关注的是两项可调预算：查询使用多少特征，以及每份已存文档保留多少特征。LightOn公告

本文介绍模型适合什么任务，这些控制项会改变什么，以及在搭建搜索服务前如何做一次小型比较。理解它不需要新建聊天应用。先准备一个问题、几份文档，再定义什么结果才算有用。

公开模型卡截图，摄于2026年10月20日。来源：Hugging Face上的LightOn。这是已发布的模型页面，并非本地推理结果；界面也说明，可下载模型不一定配有托管推理服务。

生成答案之前，先找到一组可靠的候选资料

检索器根据查询为文档排序。它不必撰写答案、总结文件，或判断公司是否应该修改政策。它当前的任务更具体：把最相关的资料排到前面。

假设内部手册有退货、配送和员工休假三页。遇到如何退回破损订单的问题，退货页应该排在前列。如果第一条结果却是休假日历，下游再流畅的答案生成器也已经拿错了依据。

因此，即使没有生成式AI，检索也有价值。客服人员可以直接打开排好序的文档，研究者可以收集段落进行比较，编程工具也可以先找到可能相关的实现，再交给人检查。

这里还有清楚的责任划分：检索负责定位证据，措辞、日期和例外仍要到原文核实。好的结果应该让人更容易抵达原始资料，而不是用一个置信度替代资料本身。

稀疏搜索维护一本有选择的通讯录

可以把搜索索引看成通讯录。传统关键词索引记录哪些文档包含某个词。学习型稀疏模型则给一小组学习到的特征分配权重，再通过双方共同激活的特征，计算查询与文档的匹配分数。

“稀疏”描述的就是这种选择性。表示空间可能有很多位置，但一段文本只使用其中一部分。倒排索引把每个活跃特征与使用它的文档关联起来，让搜索引擎集中处理相关的倒排列表。

SlideOn模型卡列出32,768个可用的学习特征，并提供独立的查询与文档剪枝控制。这些位置是学习得到的潜在特征，并不是一份能直接阅读的英语词典。不能把特征100当作“退货”的固定同义词。SlideOn模型卡

解释结果时要记住这一点。稀疏表示可以降低搜索开销，却不代表每项内部判断都能被人理解。面向用户的解释仍应给出相关原文片段和足够上下文，让人核对它为何匹配。

原创示意图。特征标记仅用于解释流程，不是从SlideOn测得的激活值。

按你实际拥有的资料选择模型

这两个名字代表相关但不同的起点，而不是能随意互换的语言设置。LightOn在发布资料中列出，SlideOn有1.74亿参数，mSlideOn有3.39亿参数。参数更多，并不能单独证明哪个更适合你的资料。10月19日发布说明

多语言标签值得进一步研究，但不能取代评估。双语资料库可能同时包含译本、内容不同的地区政策，以及不能逐字对应的术语。即使语言标签相同，也是在处理不同的检索问题。

例如，用英语问题搜索法语退款政策，是跨语言任务；用法语问题搜索法语文档，则是同语言任务。应分开记录，因为总分可能掩盖某一群读者的薄弱体验。

代码也是如此。搜索“会话恢复”的实现，与精确匹配函数名，需要不同的能力。实用搜索往往两者都要支持，因此比较时既要保留标识符原样查询，也要加入描述性问题。

第一个实验可以放进一个笔记本

先准备公开或合成文本，以及干净的Python环境。公开示例使用Sentence Transformers的SparseEncoder，它是模型加载接口，并非完整的搜索服务器。下面是对官方示例的改写，于2026年10月20日核对。文档中的用法

1. 打开模型卡，检查仓库自定义推理代码及依赖。下方加载器使用trust_remote_code=True，允许执行该仓库的Python实现；需要复现实验时，应选择检查过的版本。
2. 创建隔离环境，安装文档指定版本范围的库。
3. 编码一个查询和几份短文档。使用模型的查询与文档方法，不要手工添加前缀。
4. 将分数与实际文本对照。初次检查关注排序，而不是寻找通用分数阈值。

python -m venv .venv
# Activate .venv using the command for your shell.
python -m pip install "sentence-transformers>=6.1,<6.2" "transformers>=5.3,<6"

from sentence_transformers import SparseEncoder

model = SparseEncoder("lightonai/SlideOn", trust_remote_code=True)
documents = [
    "Customers may return a damaged order within the stated return period.",
    "Standard delivery takes three working days after dispatch.",
    "Staff should record annual leave in the shared calendar.",
]
queries = ["What should I do if my delivery arrives broken?"]

q = model.encode_query(queries, top_k=64)
d = model.encode_document(documents, top_k=512)
scores = model.similarity(q, d)
print(scores)

上述文档是虚构的教学示例，代码没有附带任何实测输出或准确率声明。先检查退货文档是否排第一，再尝试改写问题和故意设置的困难选项。

不要最简单的问题成功就停止。继续询问发货前取消、送达后破损，以及超过规定期限的退款。如果资料库没有答案，测试应揭示这一缺口，而不是奖励看似漂亮却不相关的结果。

两项预算回答两种不同的成本问题

查询剪枝限制提问时使用的特征，文档剪枝限制索引中每项保存的特征。对大型服务而言，第一项影响每次搜索重复执行的工作，第二项还影响搜索间隙持续保存的索引。

有效的实验一次只改一个预算。先固定文档表示，调整查询剪枝，再尝试其他文档预算。如果两者同时改变，结果变化也很难说明究竟是哪项调整造成的。

没有通用的“足够小”设置。短FAQ、多语言档案和软件仓库，在语言、长度、重复程度上的分布各不相同。适合宽泛问题的配置，可能丢掉区分两个近似流程的罕见细节。

原创实验设计。这些是比较条件，不是基准结果，也不是生产环境推荐参数。

把质量、时间和存储分列记录。如果搜索变快，但相关文章掉出第一页，速度改善就有代价。如果更大的索引没有改善用户真正提出的问题，额外存储也未必值得。

基准分数不等于响应时间

模型卡报告，SlideOn未剪枝设置在BEIR-15上的nDCG@10为56.68。这是跨基准数据集的排序质量报告值，不是某个答案正确的概率，也不是毫秒数。公开评估

LightOn的效率讨论区分检索FLOPS代理指标与实测延迟，也区分文档非零元素数与以字节计算的索引大小。比较表也应保留这些区别。数学代理指标解释机制，运行测量才说明系统实际做了什么。

即使是小规模评估，只有秒表也不完整。初次加载模型、编码文档、构建索引和重复查询是不同阶段。应单列冷启动与热搜索，并说明计时是否包含查询编码。

质量分数同样需要谨慎。检索器可能找到正确文件，却把长文中的错误段落排到前面。记录判断单位究竟是文件、章节还是段落，并在所有候选方案中使用同一单位。

三类实际资料能让取舍更清楚

操作手册适合作为起点，因为预期结果通常明确。写下退货、发货延迟、账号访问等问题，为每题指定权威页面。加入与页面标题措辞不同的问题，避免只测试标题匹配。

多语言项目档案又增加了一层挑战：同一主题可能出现在会议笔记、翻译公告和旧计划里。要借助元数据区分现行政策与历史讨论。语义相似度不能决定组织应遵循哪个版本。

开发者文档会加入精确字符串和近重复内容。超时问题可能同时需要概念指南与配置键。保留词法搜索作为基线，检查混合方法增加的复杂度能否在实际问题上得到回报。

这些是建议的评估场景，并非已部署案例，目的是让验收标准具体化。每种场景最重要的产物，都是他人可以审阅的问题列表、认可来源和观察到的排名。

把第一次比较缩到能够完成的规模

可以先用大约30个代表性问题，而不是无限扩充查询。把它们分成常规查找、改写、歧义和资料无法回答的问题。这只是建议的起步方案，并非具备统计代表性的基准。

调参前，先请领域专家判断预期结果。否则，每次意外排名都容易催生对问题“真正意思”的新解释。另留一组未动过的问题做最终检查，避免设置只是记住开发示例。

记录模型版本、预处理规则、分块大小、剪枝设置和机器信息。任何一项改变都可能影响比较。别人能重复的小实验，比输入已经失踪的大分数更有价值。

最后用人们实际使用的屏幕尺寸检查结果。即使第一项正确，标题截断到无法辨认，或摘要隐藏了关键句，用户体验仍然失败。检索质量与界面质量，就在人决定打开哪个结果时交汇。

更好的搜索，让人更快回到原始资料

我们认为，SlideOn实用的想法在于把质量与资源预算拆成可以实验的控制项。比起假定每个搜索问题都需要更大的回答模型，这是更切实的起点：保留问题，改变表示，再观察人们实际能找到什么。

从团队反复找不到的那份文档开始。如果换一种说法，新检索器仍能稳定把它推到前面，你就有了可以继续建设的具体改善。目的地仍是可阅读的原始资料，模型的工作是缩短抵达它的路径。

来源与媒体

核对日期：2026年10月20日。安装示例改编自公开模型卡，不代表已安装、运行本地推理或进行独立基准测试。截图由作者拍摄，展示Hugging Face上的LightOn公开模型页；两张示意图为原创。素材来源和许可说明见媒体记录。

• LightOn发布说明，2026年10月19日
• SlideOn模型卡与用法
• mSlideOn模型卡与语言信息
• 训练与评估仓库

把问题和证据放在一起

把查询集、来源链接和审阅笔记一起保存，让后续比较回答同一组问题。Telli.sh可以帮助整理这份研究记录。创建Telli.sh账号