一种更适用于 Voice Agent 的 RAG 方案

📖 目录导航

• 01. 先说清楚问题:传统 RAG 为什么不适合 voice
• 02. Moss 是什么
• 03. 发布者与公司背景
• 04. 项目历史、目标与 benchmark
• 05. 它到底怎么做到 sub-10ms
• 06. 关键实现:几个值得注意的点
• 07. 适用场景
• 08. 不适用场景
• 09. 给我们的启发

做过 voice agent 的人都知道那个尴尬的停顿:用户话音刚落,agent 卡了半秒甚至一秒才开口。文字聊天里这点延迟无所谓,但放到语音对话里,它会直接把"在和一个聪明东西说话"的错觉打碎。我自己排查过几轮这种卡顿,结论很一致:大部分时间不是花在 LLM 推理上,而是花在检索这一跳上。刚好找到 Moss 这个项目,思路正好是冲着这个问题去的,值得拿出来认真讲一讲。这篇文章我会把它的来龙去脉、技术取舍、适用边界都梳理清楚,也讲讲它给我的几点启发。

01. 先说清楚问题:传统 RAG 为什么不适合 voice

语音对话对延迟的容忍度,和文字 RAG 完全不是一个量级。人在对话里对"对方接话"的预期窗口很窄,超过几百毫秒就会感觉到不自然。把一次典型的 voice agent 回合拆开看,延迟大致分布在这几段:

• ASR(把语音转成文字):流式可以做到很低,问题不大。
• 检索(RAG 取上下文):这里是重灾区。
• LLM 推理:首 token 延迟有优化空间,且可以流式吐字。
• TTS(文字转语音):流式同样可以边生成边播。

ASR、LLM、TTS 这三段,业界这两年都在往流式、低延迟方向卷,优化得差不多了。唯独检索这一段,大多数团队还在用"标准 RAG"那套:

• query 先调一个嵌入服务(很多是云端 API)向量化;
• 拿到向量再走网络去访问云端向量数据库(Pinecone、Qdrant 之类);
• 数据库做近邻检索,结果再走网络回来。

这条链路里有两次网络往返和一次外部嵌入调用。单看每一步都不算离谱,但叠在一起,p95 经常就飘到几百毫秒甚至上秒。而且它是"回合里串行卡死"的那种延迟——不像 LLM 吐字可以流式遮掩,检索没回来,后面什么都动不了。这就是 Moss 想解决的事:把检索这一跳从链路里基本抹掉。

02. Moss 是什么

一句话:Moss 是一个为对话式 AI 设计的、运行在你应用进程内的实时语义搜索运行时,主打 sub-10ms 的本地检索。几个需要先厘清的关键点:

• 它不是数据库,是 runtime。 你不用管理集群、不用调 HNSW 参数、不用操心分片。你只做三件事:索引文档、把索引加载进 runtime、查询。
• 检索发生在你自己的进程里。 runtime 嵌入在你的应用中,通过 HTTPS 把索引拉下来放进内存,之后查询不再离开进程。这是它低延迟的根本来源。
• 嵌入模型内置,不强依赖 OpenAI。 默认自带小模型,也支持自带嵌入。
• 支持纯本地运行。 据官方文档,本地模式不需要任何网络访问,认证只用于同步、托管嵌入这类可选的云功能。
• 开源,协议是 BSD 2-Clause。

需要特别提醒的一个坑:搜 "Moss" 会撞名。复旦那边有个叫 OpenMOSS 的开源项目(MOSS 对话模型、MOSS-TTS 语音合成),和这个做检索的 Moss 完全是两码事,别搞混了。本文讲的是 usemoss.dev / moss.dev 这家。

03. 发布者与公司背景

据 Moss 在 Y Combinator 的 launch 帖,这家公司的背景是这样的:

• 创始人是 Sri Raghu Malireddi 和 Harsha Nalluru,两人相识 8 年以上,背景集中在机器学习、高性能计算和开发者体验。
• Sri 此前是 Grammarly 和 Microsoft 的 ML Lead,做过跑在 Office、Bing、Grammarly 上、服务数百万用户的 LLM 和个性化系统;据其自述,个性化工作为 Grammarly Keyboard 带来 300% 留存增长,并把模型扩展到 4000 万+ 日活;在 ACL 等会议发过论文,持有实时 ML 相关专利。
• Harsha 此前是 Microsoft 的 Tech Lead,主导过 Azure SDK 的核心栈,支撑 400+ 云服务、npm 上每周 100M+ 下载量。
• 公司归属 YC 2025 年秋季批次(Fall 2025 / F25),定位 B2B,标签是 Developer Tools / SaaS / AI,总部在旧金山。

他们自己讲创业动机讲得挺实在:在 Microsoft 和 Grammarly 做大规模 agentic 系统时,反复撞到同一堵墙——检索延迟让再聪明的模型也显得"没活气"。Moss 就是冲着把多跳检索栈塌缩成一个本地优先的实时 runtime 去做的。这个背景我觉得值得留意:两位都是在大厂做过真实规模系统的人,一个偏 ML/个性化,一个偏 SDK/工程基建。Moss 这种"既要嵌入模型质量、又要极致工程延迟、还要把 SDK 做得好用"的活,恰好卡在这两人的交集上。

专注大模型的电话智能体

了解更多

04. 项目历史、目标与 benchmark

时间线(据 YC launch 帖):launch 帖发布于 2025 年 10 月底,对应 YC 秋季批次。所以这是个相当新的项目,2026 年中的当下还处在早期高速迭代阶段——GitHub 上能看到几天前还在提交。目标很清晰,就是一句话:把对话式/语音 AI 里的检索延迟打到 sub-10ms,让对话"无感"。商业进展(据其自述,数字未经第三方核实):6 个企业级 design partner、3 个付费客户、7 个在评估;在和 Pipecat(Daily.co)、LiveKit 这类语音 AI 编排公司深度合作,把 Moss 嵌进它们的实时检索管线;用量和收入周环比约 100% 增长。这类早期自报数据看个趋势就好,不必当硬指标。benchmark 情况,这部分要拆开看,因为前提条件很重要:

• 测试条件:10 万文档、750 次实测查询、top_k=5。
• 硬件:MacBook Pro(M4 Pro, 24GB)。
• 口径:测的是端到端查询延迟,包含嵌入 + 检索,p99 为个位数毫秒。
• 一个值得肯定的诚实点:Moss 把嵌入计算也算进了延迟里,而它对比的竞品用的是外部嵌入服务,Pinecone、Qdrant 用的是云端检索——也就是说对比口径里,Moss 把自己最重的那部分也算进去了。

我的判断:这个数字真实但有边界。M4 Pro 是很强的硬件,单核性能和内存带宽都顶;10 万文档这个量级,索引能整个塞进内存。官方文档自己也加了"hardware-dependent"的限定词。换到一台普通云服务器 CPU、或者文档量级上到千万,数字一定会变。所以别把"sub-10ms"当成放之四海皆准的承诺,它是特定硬件、特定数据规模下的本地检索延迟。

05. 它到底怎么做到 sub-10ms

这是我最关心的部分。直觉上,用一个通用大嵌入模型,光 query 向量化在 CPU 上就要几十上百毫秒,根本塞不进 10ms。所以它一定在几个地方做了取舍。拆开看,是四个工程决策叠加的结果:第一,消掉网络跳数(省下的大头)。 runtime 跑在你的进程里,索引拉到本地内存后,查询不出进程。传统 RAG 链路里那两次网络往返直接归零。它的 Python 包名叫 inferedge-moss、npm 包叫@inferedge/moss,"InferEdge" 这个命名本身就点明了思路:推理在边缘/在进程内发生。第二,默认用小嵌入模型。 据官方文档,内置两个模型:

• moss-minilm(默认):快、轻,面向边缘/离线。
• moss-mediumlm:精度更高,性能也还可接受。

默认的 MiniLM 系是典型的几十 M 参数级小型句向量模型(标准 all-MiniLM 输出 384 维)。正因为模型小,query 向量化才能压进个位数毫秒。 代价是嵌入质量、泛化能力弱于 OpenAI 那种大模型——但他们没藏着,而是直接把"质量 vs 延迟"做成了 moss-minilm / moss-mediumlm 这个可选旋钮交给你。第三,把慢活挪到离线/云端。 这是理解它架构的关键心智模型:延迟敏感和不敏感的工作彻底分开。文档侧的嵌入(量大、慢)是预先算好的,打包成一个静态索引产物;线上查询只做两件轻活——query 过一次小模型 + 内存里做近邻检索。第四,内存内检索 + 框定数据规模。 10 万级文档整个进内存,ANN 检索本身就快。真正的瓶颈从来是前面的嵌入和网络,这两块上面都绕开了。一句话总结这个"魔法":它没有发明更快的向量化算法,而是把 RAG 链路里三个最慢的环节分别消掉了——网络往返(进程内)、文档嵌入(离线预算)、大嵌入模型(换成内置小模型)。剩下的自然能进个位数毫秒。

06. 关键实现:几个值得注意的点

SDK 用起来很薄,这里只贴有信息量的部分(完整 API 以官方文档为准,下面标注的方法签名以官方示例为准,部分参数我会注明出处)。

创建索引时选模型,是第一个要做的取舍决策:

# 省略 client 初始化
# 关键:建索引时就定下嵌入模型,直接决定后续延迟/质量的基线
# moss-minilm  -> 默认,最快,适合 voice 这种延迟敏感场景
# moss-mediumlm -> 精度更高,延迟换质量
client.create_index(
    name="support-kb",
    model="moss-minilm",   # 据官方文档的模型命名
)

分块策略直接影响召回,据官方文档的建议值:

• 每块约 200–500 tokens;
• 重叠 10%–20%;
• 块越小召回越好,重叠用来保住上下文连续性。

voice 场景我倾向于偏小的块(靠近 200),因为语音回答本身要短、要快,检索粒度细一点更容易命中那一两句要点。

查询时的两个旋钮是 voice 调优的核心:

# top_k:返回多少条。voice 场景别贪多,top_k 太大反而拖慢下游 LLM 拼 prompt
# alpha:语义(1.0) vs 关键词(0.0) 的混合权重,默认偏语义
results = client.query(
    index="support-kb",
    text=user_utterance,
    top_k=3,        # voice 里我一般压到 3~5
    alpha=0.7,      # 据官方文档:alpha 越高越偏语义,留点关键词权重对专有名词更稳
)

这里有个容易踩的坑:voice agent 的 query 是 ASR 转出来的,经常有口语化、识别错字、专有名词错拼。纯语义(alpha=1.0)对这类噪声不算稳,适当保留一点关键词权重(把 alpha 调到 0.6~0.8 之间)对人名、产品名、订单号这种 token 反而更鲁棒。这是我会重点调的参数。集成进语音管线的位置,概念上是这样:

• ASR 出文字 → Moss 本地检索拿上下文 → 拼进 LLM 的 prompt → LLM 流式吐字 → TTS 流式播报。

官方提供了 Pipecat、LiveKit、Vapi、ElevenLabs、Agora 等编排框架的集成示例。关键在于:Moss 这一跳现在是进程内本地调用,不再是管线里那个会卡死的网络节点。 具体集成代码各框架不同,以对应官方示例为准。

07. 适用场景

我会在这些情况下认真考虑用它:

• 延迟敏感的 voice agent / 实时语音对话。 这是它的主场,sub-10ms 检索能实打实把那个尴尬停顿干掉。
• 客服、copilot 这类知识库规模可控的场景。 十万级、百万级文档、且更新不算极端频繁,正好落在它内存内检索的甜区。
• 隐私/合规要求高、数据不能出端的场景。 支持纯本地、离线运行,敏感上下文留在设备或自己进程里。
• 想砍掉向量数据库这层基建和 egress 成本的团队。 不用再养一套 Pinecone/Qdrant,也省掉反复进出云的流量费。
• 浏览器 / 端侧的客户端语义搜索。 它有独立的 WebAssembly SDK,能在浏览器里不带服务器做语义搜索。

08. 不适用场景

这些情况我会谨慎,甚至直接不用:

• 超大规模语料(千万、上亿文档)。 内存内检索的前提就被打破了,sub-10ms 的承诺也不再成立。这种规模该上专门的分布式向量数据库。
• 对嵌入质量要求极高、且不在乎那点延迟的离线场景。 比如批量文档分析、离线检索增强,这时候用大嵌入模型 + 成熟向量库,质量上限更高,延迟无所谓。
• 写入极其频繁、要求强一致的场景。 它的模型是"云端/离线建索引 → runtime 拉下来查",本质偏读多写少。如果你的数据每秒都在大量变动且要求立刻可查,这套打包-分发模型会别扭。
• 早期项目稳定性敏感的生产线。 项目很新(2025 秋 launch),API 和能力都在快速变。上生产前要自己压测、要做好版本锁定和回归。
• 需要复杂检索/重排链路的场景。 如果你重度依赖多路召回、复杂 rerank、图检索这类能力,它当前的定位是"快"而非"全",未必覆盖得到。

09. 给我们的启发

抛开 Moss 这个具体产品,我觉得它的思路对做工程的人有几点实在的启发:

• 延迟优化的第一性原理,是先消灭网络跳数,而不是去抠单步算法。 大家容易一上来就想着换更快的 ANN、量化向量,但 voice 场景里真正的大头往往是那两次网络往返。把检索搬进进程内,一下子省掉的比任何算法微调都多。先看链路结构,再看单点性能。
• 把"质量 vs 延迟"做成显式的旋钮,而不是替用户偷偷决定。 moss-minilm / moss-mediumlm 这个设计很务实——承认小模型质量有损,但把选择权交出来。我们自己做系统时也该这样:别假装没有取舍,把取舍暴露成可配置项。
• 按延迟敏感度给工作分层,该离线的坚决挪到离线。 文档嵌入慢就预先算好打包,线上只留最轻的 query 嵌入 + 内存检索。这个"重活离线、轻活在线"的分层思路,适用面远不止检索。
• 场景收窄反而是优势。 它不试图做一个通用向量数据库,就盯着"对话式 AI 的实时检索"这一个场景死磕。正因为收窄,才敢做出"进程内 + 小模型 + 内存检索"这套激进取舍。做基础设施时,想清楚自己服务的那个具体场景,比追求大而全更有价值。
• 对自报 benchmark 要看口径。 Moss 这个 benchmark 我愿意肯定,是因为它把自己最重的嵌入也算进了延迟、还写明了硬件和数据规模。反过来,我们看任何性能数字时,第一反应都该是"它的测试条件是什么、口径公不公平",而不是直接采信那个数。

最后给个落地建议:如果你手上正好有延迟敏感的 voice 项目,知识库又在十万到百万这个量级,Moss 值得拉下来做一轮真实压测——但务必用你自己的语料、你自己的目标硬件去测,别直接信 M4 Pro 上那个数。它适不适合你,压测说了算。