把上下文感知塞进 AR 眼镜：端侧检索的三个约束

AR 眼镜这条线上，最难的其实不是「能不能显示」，而是「它该知道什么」。显示模组在过去两年进步很大，但一个只会把通知投到眼前的眼镜，用户戴三天就摘了。

真正让眼镜有用的，是它能不能理解你正看着的东西。

先摆物理约束

• 重量和散热决定了算力上限，眼镜本体放不下大模型。
• 续航决定了不能一直跑重负载推理，必须有休眠与唤醒策略。
• 摄像头和麦克风常开，隐私成本比算力成本更敏感。

这三条决定了架构只有两种：端侧小模型 + 云端补充，或者眼镜只做采集与渲染、算力全放手机或边缘节点。前者延迟低但能力弱，后者能力强但依赖网络。

为什么需要上下文感知

通用的语音助手在眼镜上几乎没用，因为用户问的往往是「眼前这个东西是什么、该怎么做」。这类问题的答案不在通用知识里，而在你当下的场景里。

所以检索不能只按语义相似度走，还要带空间和时间两个维度：你站在哪、看着什么、刚才做了什么。这就是上下文感知检索要解决的问题。

端侧检索的三个约束

内存是第一约束。端侧能常驻的向量索引规模有限，所以索引必须分层：热点内容常驻，冷数据放边缘或云端按需拉取。

延迟预算怎么分

我的经验值是：感知环节控制在 60 毫秒以内，检索 200 毫秒以内，生成必须流式返回第一句。超过这个量级，用户就会觉得「它反应慢」，而不是「它在思考」。

生成环节最容易被低估。很多人把完整答案生成完再显示，结果是用户已经移开视线了。

隐私边界要先定

摄像头常开意味着数据流向必须提前想清楚。三条底线：

1. 原始视频不上传，只在端侧抽特征。
2. 特征有有效期，过期即弃，不做长期画像。
3. 用户能一键看清当前采集了什么、存在哪里。

这三条不是合规装饰，而是决定用户会不会长期戴的前提。

什么场景真的成立

维修、巡检、导览这三类场景共同点是：信息需求密集、双手被占用、内容相对封闭。封闭意味着索引规模可控，也意味着端侧检索真的够用。

反过来，开放式的闲聊和通用搜索，眼镜这个形态并不占优势。

眼镜之外还需要什么

• 一个稳定的锚点系统。空间定位漂移是所有上层功能的敌人，漂了之后检索结果就会错位。
• 一套降级策略。网络断开、模型加载失败、电量偏低，每种情况都要有明确的界面表现，而不是黑屏。
• 一个明确的唤醒方式。抬手、注视、语音三种触发方式各有误触率，必须选一个主通道，其余作为补充。

第二点常被当成工程细节放到最后做，但它决定了用户第一次遇到异常时会不会直接放弃。

补一句：上面这些约束里，隐私那条最容易被推迟，也最不该被推迟。硬件方案可以迭代，信任一旦损耗就很难补回来。

免责声明：本文为技术方向讨论，所述判断基于公开信息与个人理解，不构成任何产品选型或投资建议。