Dilema Eksekusi Query pada Pipeline Geospatial AI

Pola Text-to-Spatial-SQL atau GeoSQL kini banyak digunakan oleh LLM agent untuk menganalisis data geospasial berdasarkan perintah natural language. Tantangan utama implementasi ini terletak pada lokasi eksekusi query SQL yang dihasilkan LLM: dijalankan terpusat di server database menggunakan PostGIS, atau di-offload langsung ke browser pengguna melalui DuckDB-Wasm.

Pilihan arsitektur ini berdampak langsung pada biaya infrastruktur database, latensi rendering data spasial berukuran besar, konkurensi analitik, serta keamanan eksekusi kode dinamis (SQL injection dan DoS query).

Arsitektur 1: Server-Side Execution dengan PostGIS

Pada pendekatan klasik, LLM menghasilkan dialek PostgreSQL/PostGIS. Server API mengeksekusi query tersebut pada database terpusat, mengonversi hasilnya menjadi GeoJSON, lalu mengirimkannya ke klien.

-- Contoh query spatial join yang digenerate oleh AI agent
SELECT 
  c.id,
  c.name,
  ST_AsGeoJSON(ST_Simplify(c.geom, 0.001)) AS geom,
  COUNT(p.id) AS point_count
FROM boundaries_kabupaten c
LEFT JOIN points_of_interest p 
  ON ST_Contains(c.geom, p.geom)
WHERE p.category = 'logistics_hub'
GROUP BY c.id, c.name, c.geom;

Kelebihan PostGIS

  • Spatial Indexing Matang: Memanfaatkan spatial indexing canggih (GIST/SP-GIST) untuk menangani dataset terabyte secara efisien tanpa saturasi memori.
  • Fungsi Spasial Lengkap: Mendukung ribuan fungsi OGC compliant standar (ST_Buffer, ST_Intersection, ST_Union, Voronoi) dengan presisi geodesik tinggi.
  • Data Freshness: Kueri selalu dijalankan pada layer transaksi data terbaru (OLTP dan spatial OLAP terintegrasi).

Kelemahan dan Risiko

  • Database Compute Spikes: Analitik spasial ad-hoc dari LLM membebani CPU database utama. Kueri non-optimal dapat menyebabkan full table scan spasial yang menghabiskan connection pool.
  • Serialization Overhead: Konversi geometri kompleks ke GeoJSON berbasis teks menghasilkan payload HTTP berukuran besar yang memperlambat browser parsing.

Arsitektur 2: Client-Side Execution dengan DuckDB-Wasm

Dalam pendekatan client-side, browser memuat data spasial statis dalam format ringkas (seperti Apache Parquet atau GeoParquet) via CDN/S3. DuckDB-Wasm berjalan di background thread browser via Web Worker, mengeksekusi spatial SQL hasil output LLM langsung pada client compute.

import * as duckdb from '@duckdb/duckdb-wasm';

// Inisialisasi engine DuckDB-Wasm di browser
const JSDELIVR_BUNDLES = duckdb.getJsDelivrBundles();
const bundle = await duckdb.selectBundle(JSDELIVR_BUNDLES);
const worker = new Worker(bundle.mainWorker);
const logger = new duckdb.ConsoleLogger();
const db = new duckdb.AsyncDuckDB(logger, worker);
await db.instantiate(bundle.mainModule, bundle.pthreadWorker);

const conn = await db.connect();

// Install & load extension spatial
await conn.query(`INSTALL spatial; LOAD spatial;`);

// Eksekusi query analitik dari remote GeoParquet
const query = `
  SELECT 
    id, 
    name, 
    ST_AsGeoJSON(geom) AS geojson
  FROM read_parquet('https://cdn.example.com/data/facilities.parquet')
  WHERE ST_Within(geom, ST_MakeEnvelope(106.8, -6.3, 107.0, -6.1))
`;
const result = await conn.query(query);
console.log(result.toArray());

Kelebihan DuckDB-Wasm

  • Zero Database Compute Cost: Seluruh beban CPU dialihkan ke browser perangkat pengguna. Biaya server analitik berkurang menjadi sekadar biaya static hosting storage.
  • Native Columnar Format: GeoParquet menerapkan kompresi dictionary dan bounding box filtering (Parquet statistics) melalui HTTP range requests tanpa mengunduh seluruh file.
  • Isolasi Total: Query SQL non-optimal hasil halusinasi LLM tidak berdampak pada pengguna lain atau ketersediaan database pusat.

Kelemahan dan Batasan

  • Cold Start & Resource Limit: DuckDB-Wasm butuh mengunduh file binary WebAssembly (+ extension spatial). Lingkungan browser juga dibatasi oleh batas memori per tab (biasanya 2-4 GB).
  • Stale Data: Hanya ideal untuk dataset geospasial analitik yang bersifat read-mostly atau data snapshot.

Perbandingan Matriks: PostGIS vs DuckDB-Wasm

Aspek Arsitektur Server-Side (PostGIS) Client-Side (DuckDB-Wasm)
Biaya Compute Tinggi (linear dengan jumlah pengguna dan query LLM) Nol (komputasi berjalan di CPU client)
Format Transfer GeoJSON (berukuran besar, parsing lambat) GeoParquet via HTTP Range Request (sangat terkompresi)
Keamanan Sandbox Perlu restricted user/read-only pool & query timeout Aman secara native (berjalan di browser sandbox pengguna)
Dataset Size Tidak terbatas (TB hingga PB dengan indexing) Terbatas (efektif hingga beberapa ratus MB data terkompresi)
Konkurensi AI Rentan terhadap bottleneck connection pool Skala tak terbatas tanpa degradasi ke pengguna lain

Strategi Implementasi: Hybrid Architecture

Alih-alih memilih satu teknologi secara kaku, pendekatan modern Geospatial AI menggabungkan keduanya melalui pola hibrida berdasarkan konteks query:

  1. Server Tier (PostGIS): Dialokasikan khusus untuk ingest data real-time (misal: GPS tracking), query topologi berat (ST_Buffer berpresisi tinggi), dan filtering data awal dari tabel berukuran raksasa.
  2. Data Cache (GeoParquet): Pipeline batch mengekspor snapshot data geospasial ke GeoParquet yang disimpan pada object storage secara berkala.
  3. Client Tier (DuckDB-Wasm): Query interaktif hasil perintah AI agent diarahkan langsung ke DuckDB-Wasm untuk visualisasi ad-hoc, aggregasi lokal, dan respons map rendering tanpa jeda round-trip network.

Catatan Produksi: Selalu terapkan statement_timeout ketat pada PostgreSQL jika mengizinkan LLM mengeksekusi raw SQL secara server-side untuk mencegah query rekursif atau cartesian join yang tidak terkendali.