GeoSQL：给AI看地图使其准确性提高4倍（韩文）
GeoSQL是一种地理空间分析技能，通过将地图可视化反馈整合到AI代理循环中，显著提高了空间查询的准确性。它解决了AI仅基于文本数据时无法检测到的几何错误（如多边形异常或坐标偏移），并通过数据库探索、成本预估、结果验证和地图渲染等步骤实现自主校正。与Dekart配合使用时，性能提升可达4倍。文章还讨论了局限性，如仅BigQuery支持成本控制、测试规模有限等。
在地理数据分析中，最常见的错误是无法从数字中察觉的。SQL查询可能正常执行，数字也看似合理，但一旦绘制成地图，就会暴露出诸如首尔麻浦区覆盖整个首尔或同一地区被重复统计的问题。GeoSQL正是将“查看地图”这一步嵌入到AI循环中，从而解决这类问题。
GeoSQL是什么？
GeoSQL是为Claude、Codex、GitHub Copilot等AI代理添加的地理空间分析技能。其核心理念是：“在代理循环中放入地图——纯文本无法察觉的错误，地图能一目了然。”用户用自然语言提问，AI自动编写空间SQL并渲染结果地图，然后自我审查，发现异常即修正并重新执行。它支持PostGIS、BigQuery、Snowflake和Wherobots，无需SaaS账户即可本地部署。
为什么传统AI代理不够？
首先，AI无法查看地图。传统代理仅接收文本表格结果，例如要求分析“伦敦各区的学校可达性”，代理获取数值后即报告完成。但若伦敦金融城（约3平方公里）被错误映射为大伦敦（约1572平方公里）多边形，数值看似正常，地图却一目了然。其次，空间SQL因数据库而异：PostGIS用ST_Distance，BigQuery用ST_DISTANCE，但坐标处理方式不同，AI容易混淆。此外，大数据空间查询成本不可预测——一次全表扫描可能花费数十美元，而代理通常不做成本评估。
GeoSQL的工作流程
以“在首尔江南区显示与竞争便利店距离远且人流量大的前10个商圈”为例：
- 数据库探索：AI直接读取数据库的元数据（表、列），而非猜测，并自动扫描Overture Maps的公共数据集。
- SQL编写：根据连接的数据库自动选择合适的空间函数。
- 成本预检（仅BigQuery）：执行前估算扫描数据量，默认上限10GiB，超出则自动重写为更经济的查询。
- 结果验证：检查多边形总面积或线总长度是否合理，例如过滤“江南区面积大于首尔总面积”的异常。
- 地图渲染与反馈：通过Dekart将结果渲染为Kepler.gl地图，AI查看地图并发现视觉错误（如多边形过大、点落在海上），然后修正SQL并重新执行。
GeoSQL团队的基准测试显示，开启地图反馈循环后性能提升4倍。
Dekart：地图渲染引擎
Dekart是Kepler.gl的自托管后端，使用Docker一行命令即可运行：docker run -p 8080:8080 dekartxyz/dekart。它无需配置，可部署在内部服务器或本地。数据库认证通过用户本地CLI（bq、snow等）完成，避免AI获取仓库密码。
实际使用示例
通过pip或插件安装GeoSQL，启动Dekart后，可输入类似“/geosql 显示首尔九老区主要道路5公里半径内的EV充电站密度”的指令。GeoSQL会从Overpass API收集数据，用Haversine公式计算密度，并归类渲染为交互式地图，清晰揭示充电基础设施空白区域。
文本代理 vs GeoSQL
传统文本代理：几何错误检测仅限数值异常，架构猜测，SQL方言易混淆，无成本控制，输出表格。 GeoSQL：地图视觉验证，从数据库直接探索架构，引擎自动匹配SQL方言，执行前成本估算并自动重写，输出交互式地图，性能提升4倍。
限制
- 地图反馈功能需Dekart连接，否则与普通SQL代理差别不大。
- 成本控制仅限BigQuery，PostGIS和Snowflake直接执行。
- 基准测试较小（仅伦敦、柏林、巴黎3城8个测试用例）。
- 封闭网络环境需额外配置。
结论
AI在空间分析中犯错的根本原因并非查询能力不足，而是无法看到结果。GeoSQL的解决方案简单直接：让AI查看地图。对于需要本地处理空间数据的组织，GeoSQL + Dekart组合提供了一种将AI代理级分析保留在内部的选择。
参考链接：GeoSQL GitHub、Dekart GitHub、Dekart文档、Kepler.gl。