Kuzu kullanımdan kaldırıldı: Graphiti agent memory'yi LadybugDB ve Ollama ile tek bir dosya üzerinde çalıştırmak

Gömülü graph veritabanı Kuzu artık upstream'de bakım görmediği için, yerel graph depolamayı ona kuran geliştiricilerin bir geçiş yoluna ihtiyacı var. Graphiti Local'ın yazarının dev.to'daki yazısı bunlardan birini ortaya koyuyor: LadybugDB'ye, yani Kuzu'nun bakımlı fork'una geçmek ve Zep'in Graphiti framework'ünü agent memory için tamamen tek bir yerel dosyadan, modelleri OpenAI anahtarı yerine Ollama ile sağlayarak çalıştırmak.

Backend değişince ne değişiyor

Graphiti'nin quickstart'ı bir graph veritabanı sunucusu ve bir bulut model sağlayıcısı varsayar; ancak yazıya göre tek bir makinedeki agent memory için ikisi de isteğe bağlıdır. Kalan karar hangi gömülü dosya backend'inin kullanılacağıdır ve bu, göründüğünden daha önemlidir; çünkü yeni bilgiler yazılırken okumaların devam edip edemeyeceğini bu belirler. Üç seçenek karşılaştırılıyor: Kuzu'nun kendisi, kullanımdan kaldırıldığı için yeni işlerde kullanılmamalı; FalkorDB Lite, bakımlıdır ama dosya başına tek süreç izin verir; LadybugDB ise bir read-write açılışının yanında istediği kadar read-only açılışa izin verir — tam da bir agent'in ingestion sırasında sorgulama yapması için gereken profil.

Kuzu driver üzerinden LadybugDB

Graphiti'nin专 LadybugDB driver'ı yok. Fork, Kuzu'yu sürdürdüğü için, modül eski isme yanıt verdiğinde mevcut Kuzu driver üzerinden çalışır; bu, Graphiti import edilmeden önce sys.modules'e kaydedilen küçük bir alias ile sağlanır. Yazı, bir KuzuDriver oluşturup graph.ladybug dosyasına yönlendiren ve Graphiti'ye veren minimal bir kod parçası gösteriyor.

Bu yolun bir tuzağı var. Kuzu driver full-text index tanımlar, ancak index ve kısıt oluşturucusu hiçbir şey yapmaz; dolayısıyla index'ler hiç var olmaz ve her hybrid search bir Binder istisnasıyla başarısız olur. Çözüm, bunları ilk read-write açılışta elle oluşturmaktır; Graphiti Local'ın setup komutu tam olarak bunu yapar ve index'ler eksikken read-only açılışı reddeder.

Her yazmayı bir insan onaylıyor

Tek yazıcı kısıtıyla savaşmak yerine, tasarım bu kısıta yaslanıyor. Graphiti Local'ın MCP sunucusu altı tool sunuyor ve hepsi okuma. Bir agent bir şey öğrendiğinde, graph dosyasının dışında bir öneri (proposal) kaydeder; bir insan onaylayana ve bir drain komutu grubu uygulayana kadar graph'a hiçbir şey dokunmaz. Yazarın gerekçesi şudur: yanlış bir üretim (generation) basitçe yeniden çalıştırılabilir, ama yanlış depolanmış bir entity sonraki her retrieval'ı zehirler ve küçük bir yerel model bir toplantı notundan kötü entity'leri kendinden emin bir şekilde çıkarabilir. 0.3.0 sürümünden önce sunucunun kendisi yazma kilidini tutuyor ve diğer komutların veritabanına erişimini engelliyordu; artık okuyucular dosyayı read-only açıyor ve drained değişiklikleri yeniden başlatma olmadan alıyor.

Bir dizüstünde ölçüldü

Yazıya göre kurulum en son Eylül 2026'da graphiti-core 0.30.1, LadybugDB 0.19 ve qwen2.5:7b ile nomic-embed-text çalıştıran Ollama ile test edildi. 32 GiB RAM'li bir Apple M5'te, model ve bağımlılık indirmeleri hariç, veritabanı kurulumu 1.3 saniye, bir tanı kontrolü 0.5 saniye, ingestion 34.4 saniye, bir sorgu 1.3 saniye ve bir güncellemeyi onaylayıp uygulama 44.7 saniye sürdü. Dolayısıyla retrieval bir agent döngüsü için yeterince hızlıyken, yerel bir modelle extraction, toplu çalıştırmaya veya gece boyu çalıştırmaya değer darboğazdır.

Embedder verinin bir parçasıdır

Embedding'ler çevresinde iki sessiz başarısızlık işaret ediliyor. Bir embedder'dan gelen vektörler, aynı model adı altında bile başka bir embedder'dan gelenlerle karşılaştırılamaz: nomic-embed-text'in ikinci bir Ollama derlemesi, orijinalinin 1.00 skor aldığı yerde depolanmış vektörlere karşı 0.80 cosine skoru aldı; hata verilmedi, yalnızca her aramada hafifçe daha kötü sıralama oldu. Boyut genişliği ikinci başarısızlık modudur; nomic-embed-text 1536 değil 768 boyut döndürür (OpenAI varsayılanı 1536 varsayar). Graphiti Local, veritabanına hangi embedder'ın yazdığını kaydeder ve bir ingestion farklı bir embedder kullanırsa çıkış yapar; doctor komutu da endpoint'i yoklar ve yapılandırılan genişlik uyuşmadığında başarısız olur.

Gömülü bir dosya ne zaman yanlış seçimdir

Yazı dört durum sayıyor. Çok kullanıcılı veya multi-tenant dağıtımlar; çünkü tek dosya, gruplar arasında zorunlu bir sınır olmayan tek graph'tır; önerilen alternatifler kullanıcı başına bir dosya ya da gerçek bir tenant sınırı gerektiğinde FalkorDB veya Neo4j'dür. Doğrudan yazması gereken agent'ler; bu tasarım bunu bilerek engeller. Toplu ingestion; burada yerel model extraction hızının tabanını belirler. Ve Kuzu driver'a uzun süreli bağımlılık; Graphiti bunu deprecated olarak işaretledi. Graphiti Local bu yüzden graphiti-core'u sabitler (pin), bu yüzden yükseltmeden önce pin kontrol edilmelidir.

Neden önemli

Kuzu'nun kullanımdan kaldırılması gömülü graph alanını belirgin bir halef bırakmadan kapattı ve bu yazı fork'un drop-in bir alternatife ne kadar yakın olduğunu gösteriyor: bir modül alias'ı ve elle yapılan bir index düzeltmesi tüm geçişi oluşturuyor. Daha geniş açıdan bakıldığında, model extraction ile kalıcı hafıza arasına insan onayı yerleştirerek bir eşzamanlılık kısıtını bir güvenlik özelliğine dönüştürüyor; bu, agent'lerin bilgi biriktirdiği her yerde kopyalanmaya değer bir kalıp. Uyarılar gerçek: kurulum, Graphiti'nin deprecated saydığı bir driver üstünde ilerliyor ve embedding taşınabilirliği, embedder değiştirmenin aramayı sessizce kötüleştirebileceği anlamına geliyor. Graphiti Local, yazarın bağımsız bir open-source projesidir ve Zep ile bağlantılı değildir ya da Zep tarafından onaylanmamıştır.