本地Gemma视觉模型补全地图盲区：为膝痛者规划"随处可坐"散步路线

一个关于"哪里能坐"的真实需求

大多数步行导航关心的是距离和时间，但对一位膝盖疼痛的老人来说，真正的问题从来不是"走多远"，而是"走累了能在哪里坐下休息"。开发者 Koushik 为自己父亲打造的开源项目 Bench to Bench，正是从这个被主流地图忽略的角度出发。

这款应用会围绕你当前位置规划一条短途环线，保证每隔不超过 150 米就有一处可以坐的地方，且全程避开台阶、碎石和鹅卵石路面。使用方式极简：授权定位、选择路线长度、点击开始，然后屏幕熄灭、手机放进口袋，接下来靠语音提示引导——"前方 70 米有座位"、"30 米后左转"、"已到一半，回程同样平缓"。整个过程屏幕只亮约十秒，剩下的时间都留给了户外本身。

Bench to Bench 应用界面

同一款应用，两座城市的巨大落差

项目最有意思的地方，是作者在两个地点测试后发现的鲜明对比。

在德国美因茨新城区，OpenStreetMap 已经标注了 431 处长椅。应用可以直接从地图数据规划出 590 米、987 米和 1294 米的多条环线，最长的一段无座位路段也仅有 149 米。地图数据充足，一切顺理成章。

但在印度加尔各答的 Kalighat-Hazra 区，OpenStreetMap 记录的可坐地点是——零。仅凭地图，应用只能给出"此处无法规划安全路线"的结论。可任何在加尔各答走过路的人都知道这是错的：茶摊的长凳、店铺的台阶、抬高的平台、矮墙，到处都能坐下休息。它们只是从未被任何地图收录。

这道数据鸿沟，正是本地视觉大模型 Gemma 填补的地方。

核心架构：Gemma 负责"看"，普通代码负责"决策"

整个项目贯穿一条铁律——Gemma 只描述照片内容，所有路线决策交给确定性代码。这条规则塑造了全部实现。

具体流程分为五步：

街道处理：从 Overpass API 获取 OpenStreetMap 数据构建步行图，代码过滤掉台阶、碎石、鹅卵石、私人通道以及坡度超过 6% 的路段。仅在美因茨就剔除了 1.4 公里的台阶和 3.4 公里的粗糙路面。
照片获取：从 Mapillary 拉取 Kalighat-Hazra 区的 165 张街景照片。
Gemma 视觉识别：Gemma 4 E4B 通过 Ollama 在作者的 RTX 5060 笔记本上本地运行，逐张分析照片并以固定 JSON 格式回答——是否有可坐处、类型、是否有台阶、路面是否破损、有无遮荫，外加一句理由。代码会校验每个回答，格式不符的照片直接记为失败，绝不猜测。
路线规划：带种子的搜索算法在座位之间跳跃，只接受每段都不超过 150 米的环线。这一步 Gemma 完全不参与。
行走体验：一个静态网页下载你周围 900 米内的街道与座位数据，在浏览器端用相同规则规划路线，GPS 将你贴合到路径上，Chrome 内置语音播报提示。

加尔各答的最终结果：Gemma 从 165 张照片中找到 7 处可坐地点（多为店铺前的矮台和平台，外加一家店门口的椅子）。基于这些，应用规划出一条 254 米的环线，全程距座位不超过 69 米。而单靠地图，什么都规划不出来。

Overpass API 是 OpenStreetMap 生态中专门用于数据查询的只读接口，允许开发者通过类 SQL 语法提取特定区域内的地理要素，例如"该边界框内所有标注为 amenity=bench 或 leisure=pitch 的节点"。与直接下载整个地区的完整地图包不同，Overpass API 支持精细的条件过滤，非常适合提取步行可用性相关的特征（路面类型、坡度标签、无障碍属性等）。Mapillary 则是一个众包街景平台，由普通用户用手机或行车记录仪拍摄上传，任何人都可以通过其 API 免费获取照片及其地理坐标。与 Google 街景不同，Mapillary 数据完全开放，这使得开发者可以将图片下载到本地、喂给本地运行的视觉模型，而无需将数据传输给第三方服务。Kalighat-Hazra 区 165 张照片全部来自 Mapillary，这也直接决定了分析结果的地理覆盖上限。

诚实的局限：数据覆盖才是真正的天花板

作者没有回避这条路线为何如此之短。该区域全部 157 张近期照片都来自同一个人，仅覆盖几条街上约 40 个点位。周边八个区域都没有近期照片。换句话说，Gemma 只能在有人拍过照的地方找到座位，600 米和 1 公里的路线根本无法实现。模型能力再强，也补不上现实世界的数据空白。

手工核验：Gemma 到底有多靠谱？

为了检验 Gemma 的识别质量，作者在查看模型答案之前，先亲手标注了 40 张美因茨街景照片，再做对比。结果颇具启发性：

问题	永远答"否"	Gemma 4 E4B	Gemma 4 E2B
有可坐处	92%	95%	95%
有台阶/高路缘	100%	60%	98%
路面破损	100%	100%	100%
有遮荫	95%	35%	45%

在"找出 3 个真实座位"这项任务上：Gemma 4 E4B 找到 2 个、误报 1 个；E2B 找到 1 个、零误报；而地图（以相机 15 米内有长椅为准）只找到 1 个、误报 4 个。

几个关键结论：

识别座位时，Gemma 在相同照片上赢过了地图。地图上标注的 15 米内长椅，常常在相机背后；而 Gemma 只报它能看见的东西。
识别台阶和遮荫时，Gemma 甚至输给了"永远答否"的死规则。E4B 在 16 张没有台阶的照片上误报"有台阶"，在 26 张没有遮荫的照片上误报"有遮荫"。因此路线规划器只采用座位这一项答案——这正是"模型负责看、代码负责决策"的理由所在。
40 张照片中只有 3 张真有座位，样本极少；且作者标注的是美因茨而非加尔各答，所以加尔各答的座位尚未经过人工核验。
速度方面，E4B 每张约 0.9 秒、E2B 约 0.6 秒，165 张照片三分钟内跑完。

开发中踩过的坑

真实的工程记录往往比成功演示更有价值。作者坦诚列出了遇到的问题：首次加载 E4B 时模型服务器崩溃两次（报错 0xc0000409），因为模型只能半数装进空闲显存，第一张照片耗时 77 秒，之后才稳定在 1 秒左右，脚本随后加入了失败重试。应用一度"话太多"——加尔各答座位间距约 20 米，首次练习步行在 254 米内播报了 23 句话，后来改为只播报下一个座位、每 40 米最多说一次"到了"，降到 12 句。此外还有黑屏步行界面被地图图层盖住的 z-index 问题、ElevenLabs 免费账户因"异常活动"被封转而改用手机自带离线语音等。作者也直言：目前还没有人真正走过一条路线，所有测试都在家中用模拟步行完成，他宁愿如实说明，也不编造一次真实步行。

为什么"开放的 AI"在这里格外重要

这个项目鲜明地展示了本地开源模型的几重价值。某人父亲走路区域的街景照片从不离开笔记本，Gemma 全程在本地 GPU 上通过 Ollama 运行，隐私无虞。每张照片推理零成本，因此逐张扫描整个社区完全可行。切换模型只需改一个单词，让 E2B 与 E4B 的对比实验变得极其廉价——结果显示大模型找到更多座位、小模型虚构更少。最关键的是，作者能够清楚看到模型在哪里失败，并围绕这些失败构建规则，而不是盲目信任它。

对许多试图把大模型塞进真实场景的开发者而言，Bench to Bench 提供了一个克制而清醒的范本：让 AI 做它擅长的感知工作，把需要可靠性的决策交还给确定性代码。

Ollama 是一个专为本地运行大型语言模型和视觉语言模型设计的开源工具，可以把 Gemma、Llama、Mistral 等模型封装成本地 HTTP 服务，调用方式与 OpenAI API 几乎相同，极大降低了本地部署的门槛。开发者只需一条命令即可拉取并启动模型，切换不同版本（如 E4B 与 E2B）也只需修改模型名称字符串。这种可替换性在本项目的对比实验中至关重要——正是得益于 Ollama 的统一接口，作者才能以极低成本同时评估两个规格的 Gemma，并将结论落实到架构决策上。Gemma 4 E4B / E2B 中的"E"代表 Efficient 系列，"4B""2B"指参数量（40亿和20亿），是 Google 专为在消费级硬件上本地运行而优化的视觉语言模型，支持图文混合输入，可以直接分析照片并输出结构化文本。