周三下午，一个开发者上传了一张五年前的毕业合影。Gemma 4扫了一眼，认出照片里站在角落的那个人，可能是他"失联多年的室友"——而这个人，恰好通过两条关系链，连到了他现在的同事。
这不是社交平台的推荐算法，而是Bondmap在做的事：把人际关系从通讯录里解放出来，变成一张可探索的地图。
大多数人对"我认识谁"这件事，其实只有碎片化的感知。LinkedIn存着工作关系，微信躺着几百个联系人，但没人告诉你：你大学室友的哥哥，正在和你现在的同事做同一个项目。Bondmap想解决的就是这个盲区——用Gemma 4的推理能力，把隐藏的关系路径显影出来。
它的交互设计很直白。用户手动添加人物，标记关系类型（紫色代表家人、绿色是朋友、蓝色是工作、粉色是恋爱关系），系统生成一张D3.js驱动的动态网络图。真正有意思的是查询环节：用自然语言问"我和Rahul是什么关系"，Gemma 4会遍历整个图谱，把"A认识B、B认识C"的多跳路径，翻译成一段人话。
开发者Manglesh Kumar选的是Gemma 4 31B密集模型，核心考量有三点。第一是关系路径推理：小模型给出的答案含糊，31B能稳定输出精确、有温度的解释。第二是128K上下文窗口——整个关系网络（几十个人、上百条连接）一次性塞进提示词，不用RAG、不用分块、不用向量数据库，Gemma 4在内存里直接做全局推理。第三是视觉理解：上传合影后，模型会结合场景、站位、肢体语言推测人物关系和场合。
技术栈方面，前端是React+Vite+D3.js，后端用Java Spring Boot，数据库Firebase Firestore，AI层调用Google AI Studio的Gemma 4接口，部署在Firebase Hosting和Railway上。整个架构偏向"重AI、轻后端"——复杂的图计算被推到模型层，工程端只做数据存取和可视化。
这个方案也暴露了Gemma 4在特定场景下的优势区间。社交图谱的规模天然受限（一个人的核心关系网通常不过百人），正好落在128K上下文的舒适区内；而"多跳推理+自然语言输出"的需求，又恰好踩中了大语言模型的长项。相比之下，传统图数据库需要写查询语句，推荐算法是黑箱，Bondmap的路径解释却能让用户看懂"为什么认识"。
不过，手动录入关系仍是门槛。开发者提到照片分析功能可以辅助建图，但识别准确率、隐私顾虑、以及"谁有权标记我和谁的关系"，都是没展开的问题。目前Bondmap更像一个概念验证：证明Gemma 4能在单轮推理中完成复杂的图遍历任务，而不依赖外部检索。
产品已上线（bondmap.web.app），代码开源在GitHub。对于想探索大模型替代传统图计算、或者对"可解释的关系发现"感兴趣的开发者，这个案例提供了一个具体的参照。
热门跟贴