从多语言语义搜索到博世数字的虚拟助手

一位电动自行车骑手输入"重置 Kiox 300 显示屏"，答案必须立即呈现——而不是 200 页的手册或十几个接近的 FAQ 链接。同样的期望适用于在嘈杂车间更新刹车固件的技工，以及在弱 Wi-Fi 展厅寻找扭矩规格的销售代表。

博世电动自行车系统作为博世集团内的独立业务部门，以 27 种语言提供数百万页的手册、发布说明和 CAD 图纸。大约 5%的内容每月都会更新。但对博世电动自行车系统而言，这不仅关乎效率，更是为了提升客户体验，确保为全球骑手、经销商和服务合作伙伴提供无缝支持。

满足这些期望迫使博世数字放弃普通关键词搜索，构建了一个能够理解跨语言意图、保持成本可预测、并在 1 秒内回答的检索引擎。

关键词搜索为何失效？

让我们谈谈旧方法为何无法跟上。自行车及其文档的世界充满了同义词、部件昵称和不断变化的术语。"显示屏"、"NYON2"或"BUI350"对骑手可能意味着同一事物，但词袋搜索引擎将每个词视为陌生词。除非你愿意手工制作无尽的同义词列表，否则召回率会急剧下降。

排版怪癖和语音转文本错误也无济于事。真实查询显示为"Kioxx 300"、"réinitialiser kios"，或者由于麦克风问题，变成语音识别乱码如"reset chaos 300"。精确令牌搜索？它们只会耸耸肩显示"无结果"。相比之下，基于嵌入的搜索对噪声输入宽容得多。

意图在翻译中也会丢失，特别是对于复杂或带有约束的查询。有人可能输入"无需笔记本电脑更新刹车固件"或"仅雨模式下的最大扭矩"。关键词搜索抓住否定词（"笔记本电脑"）并挖掘出错误文档。相比之下，现代 Transformer 模型理解用户的真实意图并相应排序结果。

结合所有这些痛点——同义词、噪声输入、意图混淆、快速变化的语言——你就得到了关键词搜索持续失误的主要原因。对博世数字而言，转向基于向量的多语言 SmartSearch 不是升级，而是生存所需。

设计更智能的搜索方式

一旦我们找出传统关键词搜索的每个缺陷，就是时候从头重新思考流程了。今天，SmartSearch 提供的每个答案都经历精确的三步旅程：从原始文档到排序结果——这个旅程为速度、准确性和多语言规模而设计。

第一步：爬取。我们自主开发的基于 Rust 的爬虫每秒处理约 25 个网页，快速导航庞大的文档库，同时保持足够礼貌从不触发速率限制——一个阅读快速但从不惹麻烦的数字图书管理员。

第二步：嵌入前的分块。HTML 被剖析以分离标题和内容，使用 LLM 将语义连贯的主题缝合在一起。然后是嵌入。得益于 OpenAI 的 Ada 002 模型（具有庞大的 1536 维度），每个内容块都准确落入语义空间。如果它听起来像"重置 Kiox 300"，我们的系统就会呈现答案，即使实际语言大相径庭。

第三步：使用混合方法排序搜索。语义搜索并非总是最佳方法。密集向量存储在向量数据库中，而 BM25 保持经典关键词搜索的参与。在查询时，我们将两者混合——70%语义，30%稀疏——然后通过 MiniLM 交叉编码器对最终候选进行决定性排序。结果？答案通常在大约 750 毫秒内出现，95%在 1.5 秒内交付——即使在那些臭名昭著的固件发布高峰期。

但所有这些性能并非没有痛苦。构建 SmartSearch 意味着撞上硬限制：每个集合 1000 万向量的上限、每次添加元数据时痛苦的重索引、32 位浮点数膨胀的存储账单，以及没有优雅的方法来压缩、量化或将存储分层到更便宜的 SSD。规模超过 800 万向量时，一切都会减慢到爬行。

SmartSearch 迫使我们进化——爬取、结构化、表示和排序——摆脱通用搜索基础设施的限制。结果是灵活、经济高效，并能流利处理电动自行车手册中的每种方言。

当搜索变成聊天

对于搜索栏，十个不完美的链接可能就足够了。但博世电动自行车系统要将其部署为全球用户基础的对话助手，就没有犯错余地——机器人通常只有一次机会。第一次检索必须激光般精确，因为我们传递给 LLM 的每个令牌都花费真金白银——如果机器人的开场白偏离目标，用户信任就会蒸发。

聊天也爆炸了数据规模。现在我们不仅从文档中检索，还要处理庞大的对话历史和实时跟进。数以十万计的聊天片段需要以短期和长期记忆的形式存储、搜索并在毫秒内呈现。在这里，我们之前向量存储的裂缝张开了：硬向量计数限制、缓慢的重索引时间、零支持量化或内置多阶段查询，以及坚持将所有向量保存在 DISC 上——膨胀预算并瓶颈速度。

旧架构的每个缺点都被聊天对更便宜、更智能和可扩展检索的无情需求放大了。

Qdrant 登场

在让几个向量数据库对抗我们最严苛的工作负载后，Qdrant 轻松胜出。在 25k 查询的多语言测试集上，它通过量化提供高于 0.96 的召回率，在 400 个并发聊天下保持 p95 延迟低于 120 毫秒，我们通过量化将 1000 万数据集的存储成本降低了 16 倍。Qdrant 不仅处理了聊天的挑战——它在其中茁壮成长。现在，突然之间，闪电般快速的聊天规模检索不仅可能，而且负担得起。

瘦身大脑，而非智能

我们的第一个原型说话流利相关，但是存储的饕餮鬼。每个文本块都包裹在巨大的 1536 维 Ada-002 向量中——数百万高精度浮点数成排吞噬我们的 SSD。必须有所改变。

突破来自 Jina Embeddings v3。切换一个标志，你得到 1024 维向量的二进制量化嵌入；切换另一个标志，1024 维向量可以通过 Matryoshka 表示学习的力量减少到 64。经过大量关于召回质量的内部测试，我们发现在 256 维度上获得最佳性能质量比。一夜之间，占用空间下降了 98%，搜索质量甚至超过了 Ada-002。在最近的评估中，这个设置优于 Ada-003，并将一些 MTEB 排行榜领先者抛在身后（我们接下来将评估 Qwen3 嵌入模型）。此外，得益于我们微调的 ModernBERT 重新排序器，任何微小损失都完全消失。

Qdrant 将这些瘦身向量变成闪电答案。因为它原生理解多阶段检索，我们现在运行两阶段搜索：与 BM25 融合的极快 256 维召回阶段，然后是基于 ModernBERT 的微调重新排序器以实现精确精度。这就是超精益操作应有的样子。

最重要的是，Qdrant 的分层存储让我们将热分片保存在 RAM 中，冷向量 chilling 在 SSD 上，再次削减存储，总存储减少 5 倍，同时 p95 延迟保持在 400 毫秒以下。混合搜索？密集分数在同一个 API 调用中与 BM25 无缝混合，因此充满拼写错误或完美查询得到同等关爱。

结果："重置 Kiox 300"的答案在交通灯变绿前闪现在骑手屏幕上——今天更轻的向量，明天更瘦身的空间，质量不打折扣。这是聊天速度的 SmartSearch——快速、节俭且 fiercely 精确，完美适合作为我们助手的骨干。

名称，而非猜测：GLiNER 如何超级充电识别

到目前为止，我们的助手能够以令人印象深刻的速度和准确性找到相关事实——但它仍在最重要的地方绊倒：名称。"我的 Kiox 300 在 v1.7.4-B 更新后闪烁 503"和"Nyon 在启动时冻结"对没有真正看到产品、错误代码或固件版本的语言模型来说几乎相同——只是名词和动词的模糊。上下文丢失；精度受损。为这个问题引入一个数十亿参数的 AI 大锤纯属过度。

突破来自一个意想不到的地方——在 LinkedIn 上的 doomscroll。就在那里：GLiNER，承诺通用、轻量级的 NER（命名实体识别）。少样本学习、CPU 快速推理，以及足够小（800 MB）的占用空间以适应我们的 Docker 镜像——GLiNER 勾选了我们甚至不知道我们有的每个框。

它不仅仅是"容易"——它是变革性的。只需少量标注示例——产品两个，错误代码两个，固件两个——GLiNER 在几分钟内学会了我们整个领域。推理几乎是瞬时的：每段少于 30 毫秒，即使在单个笔记本电脑核心上。

随着标签在聊天轮次中持续存在，上下文粘附。因此当骑手说"Kiox 300 在 v1.7.4-B 后显示 503"，然后跟进"它是否也影响 CX Gen4？"时，助手保持每个产品、错误和固件的清晰。每个答案都以手术精度路由，不再将 Kiox 误认为 Nyon，不再有猜测。

全因为 LinkedIn 滚动、800 MB 模型和几行标注文本。名称很重要。现在，终于，助手冷知道它们。

从答案到行动：下一代助手的智能体工作流

找到正确的段落是一回事。对于博世电动自行车系统助手， tasked with 支持从简单查询到复杂故障排除的多样化用户需求，执行现实世界任务——提交保修索赔、收集三个不同驱动单元的最新固件链接，或指导技工通过聊天逐步完成"显示屏重置"——需要更多。简单流程不足：现代助手需要推理、计划、协调和行动，而不仅仅是检索。

这就是智能体工作流登场的地方。

不是通过单个整体语言模型 funnel 每个查询（并希望它从不丢失细节），我们的平台编排一个专业 AI 智能体团队，每个都有明确责任。想象用户问："我的 Kiox 300 闪烁错误 503。你能检查我的固件是否过时，告诉我如何修复，如果不行就起草给支持的消息吗？"在过去，这向黑盒聊天机器人抛出一团模糊指令。现在，智能体工作流将请求分解为可管理、协调的步骤——每个智能体 picking up 它最擅长的。

过程从解析用户意图为子任务的编排器智能体开始：错误代码查找、固件验证、故障排除指南检索，以及如果需要，支持票证起草。每个子任务路由到专家智能体——例如基于产品变体和相应信息的自定义推理工作流。这些智能体咨询我们的检索骨干（为精度构建，即使有噪声查询），收集事实，交叉检查版本，并拼凑发现。

结果？智能体工作流让我们的助手超越回答"什么"——它们让它做"如何"和"下一步是什么"， chain 知识、行动，甚至人工交接，无缝。无论是简单规格查找、多步故障排除过程，还是编排现实世界跟进，智能体工作流是我们助手从搜索框跃升到对话伙伴背后的连接组织。

我们发现这种模块化、透明方法不仅提高速度——它带来新的安心。当某物损坏时，草稿日志准确显示做了什么（以及为什么）。如果过程碰壁，编排器 pivot——从不留用户在困境中，从不让重要细节落入裂缝。

结果：任务从头到尾处理，用户意图真正理解，以及信心，在底层，每个答案不仅仅是生成的运气，而是智能体协同工作的精心计划输出。那就是智能体工作流在行动——从答案到真实协助的步骤变化。

我们会再次做的——和我们不会做的

伤疤比奖杯教得更深，所以这里是三个仍然发痒的（以正确的方式）：

在宠爱模型之前抛光页面

我们曾经花了整整一周去重近乎相同的段落，砍掉样板（"© 2021 Bosch eBike Systems-保留所有权利"），并压平 FAQ 回声室，直到它们停止吞噬全新问题。搜索质量的改进？比任何新编码器、模型发布或聪明智能体所能管理的更大——远远超过。学到的教训：干净、结构良好的语料库是你在 Hugging Face 上永远找不到的最便宜升级，它让每个下游智能体更加敏锐。

将收缩纳入你的首日计划

二进制量化和维度瘦身在存储和推理上节省了小财富。但我们在启动后匆忙添加这些功能，这意味着在用户实时搜索时重新编码 1000 万个块——没有人需要的讨厌头痛。下次，压缩和大小目标放在第一个白板上，就在召回、延迟，以及现在，智能体交接兼容性旁边。节食在集体照前效果更好。而且不仅仅是存储：你的嵌入模型、向量数据库、分块策略，以及是的，智能体工作流和通信方案都需要从一开始就协同工作。

复杂查询意味着复杂智能体设计

LLMs 既是祝福也是预算破坏者——延迟、成本和"智能"都成为多智能体系统中成败变量。随着工作流变得智能体化——计划、委托、保持状态——挑战从"我们能回答这个吗？"转变为"我们能协调这个吗，可审计且高效？"保持数据清洁，早期计划你的存储和计算饮食，从不吝啬能够阅读字里行间并处理边缘情况的人。其他一切都只是模型卡上的另一行，或者现在，智能体清单。

这项合作努力，通过与博世电动自行车系统的战略投资和紧密合作成为可能，真正重塑了信息在其生态系统内访问和利用的方式。

最终，是痛苦的教训——不仅仅是漂亮的图表——将 SmartSearch 塑造成现在的系统。随着每一轮学习，我们的答案变得更快一点，更敏锐一点，也许——有一天——更接近完美一点。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享