Haritalama Araçlarında LLM Yükünü Azaltan Katman Deseni
RidgeText, GeoJSON verisini doğrudan LLM'e göndermek yerine sunucu tarafında katman kuyruğu tutarak bağlam maliyetini 125.000 token'dan yaklaşık 150 token'a indiriyor.
SMS üzerinden çalışan yangın ve rota haritalama uygulaması RidgeText, kullanıcı isteklerini yorumlamak ve araç çağrılarını yönetmek için bir LLM kullanıyor. Geliştirme sürecinde ekip, ham GeoJSON verisinin LLM araç çağrıları üzerinden geçirilmesinin pratikte imkansız olduğunu fark etmiş: 50-500KB'lık bir yangın veri seti yaklaşık 125.000 token'a denk geliyor, bu da çoğu bağlam penceresinden büyük ve maliyetli.
Çözüm olarak katman öncelikli bir mimari geliştirilmiş. Her veri getirme aracı (retrieve_wildfire_layer, retrieve_trail_layer gibi) sonucu doğrudan LLM'e döndürmek yerine sunucu belleğinde saklıyor ve LLM'e yalnızca layerId ile öznitelik sayısını içeren küçük bir onay nesnesi gönderiyor. generate_map aracı bu kuyruğu boşaltarak katmanları bir Mapbox Static API taban görüntüsü üzerine sharp ile birleştiriyor; bu yaklaşım Mapbox'ın kendi kaynak-katman-render mantığını sunucu tarafında yeniden üretiyor.
Bu tasarımın maliyeti de var: LLM, kuyruğa eklenen katmanların altındaki geometriyi göremediği için 'en yakın şehir hangisi' gibi soruları doğrudan yanıtlayamıyor ve katman kuyruğu yalnızca tek bir turda yaşıyor, çok turlu rafine etme yeniden veri çekmeyi gerektiriyor. Ekip bunu katmanları veritabanında saklayarak çözmeyi planlıyor.
Daha genel olarak bu yaklaşım, bir LLM'in akıl yürütme motoru yerine yalnızca veri borusu gibi davrandığı noktaları tespit edip bu rolden çıkarmanın bir örneğini sunuyor; büyük veri kümeleriyle çalışan herhangi bir LLM tabanlı sistem için uygulanabilir bir desen.