• 人工智能
• AI 应用
• 智能硬件
• 本地部署
• 可穿戴
• AI Agent

本篇以 OpenGlass 开源智能眼镜项目（Turn any glasses into AI-powered smart glasses）中prompts/series_1/img_24.md这份真实评测文档为骨架，深入拆解该项目为视觉智能眼镜打造的多模态图像描述管线：同一个镜头画面如何被四个不同量级的视觉语言模型（VLM）分别解读，各自的观察角度、细节偏好与文字输出格式有何差异，以及这套评测体系如何在 prompts/generate.ts 的驱动下自动批量生成。读完本文，你将理解 OpenGlass 视觉模块的模型选型、调用协议、prompt 设计，并掌握如何像仓库一样用「多模型交叉评测」验证任何一张真实场景图片的视觉理解质量。

一、评测文档是什么：一次真实场景的多模型「盲测」

prompts/series_1/img_24.md是 OpenGlass 仓库中一个非常典型的模型评测样本。它对应的原始图片是 img_24.jpeg——一张从低处仰拍的大型室内建筑空间照片：白色高天花板、两根长白色立柱、侧墙上的多个通风口、交错的灰色金属梁，背景窗户外透出树影与天空。

这份文档的主体由四个段落构成，每个段落以####标题####分隔，记录了同一个画面在四个不同视觉语言模型下的文字描述：

这种「同一输入、多模型、并列输出」的格式，正是 OpenGlass 视觉评测（vision eval）的核心组织形式：它不预设谁优谁劣，而是把不同量级模型对同一画面的理解并排展示，便于开发者对比各模型在真实佩戴场景下的表现。

二、这套文档是怎么自动生成的：prompts/generate.ts 评测驱动

这些.md评测文件不是手写的，而是由仓库根目录下的批量评测脚本 prompts/generate.ts 自动产出。脚本的逻辑非常直观：

1. 遍历prompts/下的所有系列目录（如series_1），收集其中全部.jpeg图片；
2. 对每张图片，依次调用四种图像描述测试，并把结果以####标题####的分节格式追加进对应的.md文件（即把img_24.jpeg的结果写入img_24.md）；
3. 四种测试的标题与模型一一对应：Description（默认模型）、Description (llava-llama3)、Description (llava:34b-v1.6)、Description (moondream:1.8b-v2-fp16)；
4. 全部处理完成后写回磁盘，形成你在仓库中看到的评测文档。

其中每个测试都复用同一个底层函数imageDescription(img, model)，只切换模型名。也就是说：img_24.md 中四个段落之间的差异，纯粹来自模型本身的视觉理解能力差异，而非 prompt 或调用方式的差异——这保证了评测的对照有效性。脚本里还预留了被注释掉的####Blurry####（模糊检测）测试段，说明评测体系原本还计划对图片质量（是否模糊/损坏）做一轮过滤，只是当前系列未启用。

三、底层实现：imageDescription 与 imageBlurry 的完整调用链

3.1 图像描述核心函数

评测脚本调用的imageDescription定义在 sources/agent/imageDescription.ts：

export async function imageDescription(src: Uint8Array, model: KnownModel = 'moondream:1.8b-v2-fp16'): Promise<string> { return ollamaInference({ model: model, messages: [{ role: 'system', content: 'You are a very advanced model and your task is to describe the image as precisely as possible. Transcribe any text you see.' }, { role: 'user', content: 'Describe the scene', images: [src], }] }); }

关键点：

• 默认模型是moondream:1.8b-v2-fp16，这也解释了为什么img_24.md第一个无后缀的####Description####段落与最后一个带moondream后缀的段落风格相近——它们实际是同一模型（前者用默认值，后者显式传入模型名）。
• System prompt 要求「尽可能精确地描述图像，并转写图中出现的任何文字」，这正是 OpenGlass「识别物体、翻译文字」产品能力的底层指令；user 消息则是极简的Describe the scene。观察img_24.md中各模型的输出，llava-llama3 对「窗户→树→天空」的逐层转述，可以理解为对这句指令中「precisely」的响应。
• 图片以Uint8Array二进制形式传入，由下层模块负责编码。

3.2 请求真正发往哪里：ollamaInference 与 Ollama 协议

imageDescription并不直接调云端 API，而是经由 sources/modules/ollama.ts 的ollamaInference走自托管的 Ollama 服务：

let resp = await axios.post(keys.ollama, { stream: false, model: args.model, messages: converted, });

其中converted会把每个消息里的Uint8Array图片通过 sources/utils/base64.ts 的toBase64转成 base64 字符串塞进 messages 的images字段，请求体完全符合 Ollama/api/chat协议。服务地址来自keys.ollama，即环境变量EXPO_PUBLIC_OLLAMA_API_URL（见 sources/keys.ts），README 中给出的标准配置是http://localhost:11434/api/chat。

注意：README 明确指出运行前需要先在终端执行ollama pull moondream:1.8b-v2-fp16拉取模型，因此本文档中 moondream 相关的两个段落，其输出质量直接取决于本机 Ollama 拉取的模型权重。

3.3 可靠性保障：指数退避重试

ollamaInference还包了一层 sources/utils/time.ts 提供的backoff重试机制：默认最小延迟 250ms、最大延迟 1000ms、最多 50 次失败重试，失败时打印告警。这让评测脚本在本地模型加载缓慢或偶发超时时不至于中断整批测试——也是 img_24.md 这类文档能一次跑完整批 57 张图（series_1 共 57 个样本）的工程保障。

3.4 另一条评测线：模糊检测 imageBlurry

与描述评测配套的是 sources/agent/imageBlurry.ts，它调用moondream:1.8b-v2-moondream2-text-model-f16模型，system prompt 要求「判断图片是否损坏、模糊或低质量，必须用 YES/NO 回答」。虽然当前系列文档未启用该段落（generate.ts 中相关代码被注释），但它揭示了 OpenGlass 的完整评测思路：先用模糊检测过滤无效帧，再对有效帧做多模型描述，这与智能眼镜长时间佩戴拍摄时会产出大量抖动/失焦帧的工程现实直接相关。

四、从文档反推模型行为：四个模型对同一画面的观察差异

结合img_24.md的四个输出，可以提炼出可复用的对比维度，这对读者自己跑评测脚本判读结果很有参考价值：

• 忠实度（factual grounding）：四个模型都正确识别了「白色立柱、天花板、通风口/管道、窗户」这些主导元素，说明这些元素是画面中最稳定、最显著的结构特征；差异集中在它们各自「补充」了什么。
• 细节粒度（granularity）：llava-llama3补充了「柱顶螺旋造型」「弧形金属梁」「窗外树木」；llava:34b-v1.6进一步补充了「通风管道沿墙延伸」「自然光与人工光混合」，甚至对左侧未完全入镜的大型设备给出「工业装置或博物馆展品」的猜测（带有推断性质）。
• 主观倾向（subjectivity）：llava:34b-v1.6用「宽敞而略显神秘（spacious and somewhat mysterious）」给画面定了情绪基调；moondream:1.8b-v2-fp16则强调「空无一人、显得荒凉（desolate）」——不同模型对同一中性场景的「氛围词」选择差异明显。
• 推测边界（speculation）：llava:34b-v1.6的「可能是工业设施或博物馆展品」属于模型推断而非画面实锤；而moondream的「仓库（warehouse）」判断也带有主观归类。在使用这类描述做下游问答时，需要警惕模型把推测混入事实。

这一节的观察结论可以与源码中的llamaFind/openAIFind（见 sources/agent/imageDescription.ts）呼应：OpenGlass 的 Agent 会把多张图片的描述拼接后交给 Groq 的llama3-70b-8192或 OpenAI 的gpt-4o做问答（prompt 明确要求「不要泛化、不要推测、只依据描述回答」），因此描述文本的忠实度直接决定了用户提问「这是什么地方」的答案质量。

五、如何复现这份评测：把任意一张图片变成多模型描述文档

如果你也想对任意场景图片做同样的四模型交叉评测，可按以下步骤复用 OpenGlass 的评测管线（仓库为只读，以下均为本地查看、安装与运行操作）：

1. 准备环境：克隆仓库后执行npm install（或yarn install）安装依赖；参照 README.md 配置环境变量，或在 sources/keys.ts 中填入EXPO_PUBLIC_OLLAMA_API_URL（如http://localhost:11434/api/chat）以及 Groq/OpenAI 的 key。
2. 拉取模型：在终端执行ollama pull moondream:1.8b-v2-fp16；如需复现全部四个模型，还需准备llava-llama3与llava:34b-v1.6。
3. 放置图片：把待测图片放入prompts/下任一子目录（如新建series_1同级目录），保持图片名.jpeg与输出图片名.md的命名约定。
4. 运行评测：执行 prompts/generate.ts（npx ts-node prompts/generate.ts或项目配置的等效命令），脚本会以进度条显示处理过程，最终为每张图片生成包含四个####标题####段落的 Markdown 文档。

复现后，你可以仿照上文第四节的分析维度（忠实度、细节粒度、主观倾向、推测边界）去判读任意模型的输出，快速评估某一模型是否适合作为你佩戴场景下的「默认描述引擎」——例如追求低延迟轻量推理可选 moondream 系列，追求细节丰富度可选 llava 系列。

六、结语：一份评测样本背后的完整视觉链路

img_24.md这份看似简单的描述文本，实际上是 OpenGlass 视觉智能眼镜「拍摄 → 编码 → 本地 VLM 推理 → 文本化记忆 → 下游问答」整条链路的第一环证据。从 prompts/generate.ts 的批量驱动，到 sources/agent/imageDescription.ts 的 prompt 设计，再到 sources/modules/ollama.ts 的 base64 编码、Ollama 协议与退避重试，每一个环节都在文档的四个段落里留下了可验证的痕迹。理解这份文档，就等于掌握了 OpenGlass 视觉模块的模型选型、评测方法与工程化调用方式——这套「一图四评」的范式，同样适用于任何想在边缘设备上落地多模态视觉理解能力的开发者。

• 人工智能
• AI 应用
• 智能硬件
• 本地部署
• 可穿戴
• AI Agent