HN’de yayınlandı: FastGraphRAG – Geleneksel PageRank’ten yararlanan geliştirilmiş RAG tekniği

 (github.com/circlemind-ai)
1 puan yazan GN⁺ 2024-11-19 | 1 yorum | WhatsApp'ta paylaş
  • Fast GraphRAG, yorumlanabilir ve yüksek hassasiyetli ajan tabanlı arama iş akışları için sadeleştirilmiş bir GraphRAG framework’üdür; karmaşık ajan iş akışlarını doğrudan kurmadan gelişmiş RAG’yi arama pipeline’ına eklemeye odaklanır
  • Bilgi grafiğini insanların gezinebileceği bir forma getirir; sorgulanabilir, görselleştirilebilir ve güncellenebilir kılar; alan ve ontoloji gereksinimlerine göre grafiği otomatik olarak oluşturup iyileştirir
  • Sorgu yanıtlarında ilgili bilgileri bulmak için personalized PageRank tabanlı grafik keşfi kullanır; README, bu yaklaşımın özeti olarak HippoRAG makalesine bağlantı verir
  • Örnek maliyette The Wizard of Oz için fast-graphrag $0.08, graphrag ise $0.48 olarak gösterilir; veri boyutu ve ekleme sayısı arttıkça 6 kat maliyet tasarrufunun daha da iyileştiği belirtilir
  • Python 3.10.1 ve üzeri sürümlerde çalışır; kaynak koddan kurulum ve PyPI kurulumunu destekler; OpenAI API anahtarı ayarlandıktan sonra belge ekleme ve sorgulama yapılır, aynı çalışma dizininde bilgi otomatik olarak korunur

Fast GraphRAG’nin sunduğu arama framework’ü

  • Fast GraphRAG, yorumlanabilir ve hata ayıklanabilir bilgi hedefleyen bir GraphRAG framework’üdür
  • Grafik, bilgiyi insanların gezinebileceği bir biçimde sunar ve şu işlemleri destekler
    • Sorgulama
    • Görselleştirme
    • Güncelleme
  • Gelişmiş RAG özellikleri sunarken ajan iş akışlarını doğrudan kurma ve tasarlama yükünü azaltmaya odaklanır

Başlıca özellikler

  • Büyük ölçekli çalıştırmaları hızlı ve düşük maliyetli kılacak şekilde tasarlanmıştır; ağır kaynak veya maliyet gereksinimlerini azaltma yönündedir
  • Dinamik verileri destekleyerek alan ve ontoloji gereksinimlerine uygun biçimde grafiği otomatik oluşturur ve iyileştirir
  • Veri değiştiğinde artımlı güncellemeleri destekleyerek gerçek zamanlı güncellemeyi mümkün kılar
  • PageRank tabanlı grafik keşfinden yararlanarak doğruluğu ve güvenilirliği artıran akıllı keşif sunar
  • Genel olarak asenkron yapıdadır; eksiksiz tip desteğiyle sağlam ve öngörülebilir iş akışlarını hedefler

Maliyet örneği

  • The Wizard of Oz kullanılan örnekte fast-graphrag maliyeti $0.08, graphrag maliyeti ise $0.48 olarak verilir
  • README bunu 6 kat maliyet tasarrufu olarak açıklar; veri boyutu ve ekleme sayısı arttığında tasarruf etkisinin daha da iyileştiğini belirtir

Kurulum ve çalıştırma akışı

  • Önerilen kurulum yöntemi, performans için kaynak koddan kurulum ve kararlılık için PyPI kurulumu olarak ikiye ayrılır
    • Kaynak koddan kurulum: depoyu klonladıktan sonra poetry install
    • PyPI kurulumu: pip install fast-graphrag
  • Hızlı başlangıç örneği önce OPENAI_API_KEY ortam değişkenini ayarlar
  • A Christmas Carol metni indirildikten sonra Python kodunda GraphRAG başlatılır
  • Örnek başlatmada şu değerler yer alır
    • working_dir="./book_example"
    • hikâyedeki karakterleri, etkileşimleri, yerleri ve ilişkileri analiz eden domain
    • örnek sorgu listesi
    • ["Character", "Animal", "Place", "Object", "Activity", "Event"] varlık tipleri
  • Belge grag.insert(f.read()) ile eklenir, sorgu sonucu ise grag.query("Who is Scrooge?").response ile yazdırılır
  • Aynı çalışma dizininde yeniden başlatıldığında bilgi otomatik olarak korunur
  • Yerel model kullanımı gibi durumlarda LLM eşzamanlı işlem sayısını kontrol etmek için isteğe bağlı olarak CONCURRENT_TASK_LIMIT=8 gibi bir ortam değişkeni ayarlanabilir

Örnekler ve yapılandırma seçenekleri

  • examples klasörü, kütüphanenin yaygın kullanım senaryoları için öğreticiler sunar
  • custom_llm.py, OpenAI API uyumlu dil modeli ve embedder’ı farklı şekilde yapılandırmaya yönelik basit bir örnektir
  • checkpointing.ipynb, geri döndürülemez veri bozulmasını önlemek için checkpoint kullanımını ele alır
  • query_parameters.ipynb, çeşitli sorgu parametrelerini ele alır ve with_references=True ile yanıtta kullanılan bilgilerin referanslarını dahil etme yöntemini gösterir

Tasarım felsefesi ve keşif yöntemi

  • Hedefin başarılı GenAI uygulamalarının sayısını artırmak olduğu; bunun için LLM uygulamalarının karmaşık ajan iş akışı kurulumu ve bakımı olmadan özelleşmiş arama pipeline’larından yararlanmasını sağlayan bellek ve veri araçları geliştirildiği belirtilir
  • Fast GraphRAG, mevcut sorguyu yanıtlamak için en ilgili bilgileri bulmak üzere grafiği personalized PageRank algoritmasıyla keşfeder
  • Bu yaklaşımın neden işe yaradığına dair bir özet olarak HippoRAG paper referans gösterilir

Açık kaynak ve yönetilen hizmet

  • Depo MIT License ile sunulur; ayrıntılar LICENSE.txt dosyasında yer alır
  • Hızlı ve güvenilir biçimde başlamak için yönetilen hizmet sunulur
  • Yönetilen hizmette her ay ilk 100 istek ücretsizdir; sonrasında kullanıma göre ücretlendirme yapılır
  • Yönetilen hizmet hakkında daha fazla bilgi edinmek için demo randevusu alınabilir veya docs incelenebilir
  • Katkı yönergeleri CONTRIBUTING.md dosyasındadır; sorular Discord üzerinden sorulabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-19
Hacker News yorumları

  • PageRank dışında da, yapısal verilerde RAG’i etkileyebilecek ilginç birkaç merkezilik metriği var
    Bunlardan Triangle Centrality, bir düğümün etrafındaki üçgenleri sayarak merkeziliği hesaplıyor; bu da üçgenlerin ilişkileri güçlü biçimde kapattığı, açık bağlantıların ise merkezden ağırlık çalarak merkeziliği seyreltmesi fikrine dayanıyor
    https://arxiv.org/abs/2105.00110
    Makale, bunun PageRank gibi diğer merkeziliklerden daha verimli olduğunu söylüyor, ancak GraphBLAS kullanan çalışmada 1,8 milyar kenara kadar çeşitli seyrek grafiklerde TC, bizim seyrek PageRank uygulamamızdan daha yavaştı
    Yine de grafik büyüdükçe TC daha iyi ölçekleniyor gibi görünüyor ve trilyon düzeyi kenar bölgesinde daha verimli olabilir
    https://fossies.org/linux/SuiteSparse/GraphBLAS/Doc/The_Grap...

    • Burada düğüm/kenar sayısı milyonlar düzeyinde, bu yüzden verimlilik büyük bir sorun değil
      Zaten yanıt üretiminde darboğaz, LLM’in ayrıştırdığı kısım olacaktır
      PageRank ilk adım ama daha doğru alternatifleri de test etmek isterim
      Burada kişiselleştirilmiş PageRank kullanıyoruz; yani belirli bir düğüm kümesine başlangıç ağırlığı veriyoruz, Triangle Centrality’nin bunu destekleyip desteklemediğini merak ediyorum
      Ayrıca kenar ağırlıklarına da bakıyoruz, o kısmın da mümkün olup olmadığını bilmek isterim
    • PageRank alternatifi olarak Authority Rank denediniz mi diye merak ediyorum
      https://link.springer.com/content/pdf/10.1007/978-3-030-6097...

  • Bu alanda epey çalışma yaptım ve birkaç şey öğrendim

    1. Toplama aşamasında LLM ile biraz iş yapabiliyorsanız, yalnızca BM25 tabanlı sözcüksel arama bile çok ilgili sonuçlar veriyor
    2. Embedding’ler, sorgunun ölçeği embedding deposuna koyduğunuz şeylerle kabaca aynı mertebedeyse iyi çalışıyor
    3. LLM’in sorgudan bir varsayımsal yanıt üretmesini sağlayıp, embedding aramasını bu varsayımsal yanıtla yapmak çok iyi çalışıyor
      Bu üçünü birleştirerek benzer bir bilgi ayrıştırma/çıkarma aşaması oluşturdum ve buna bir meta-prompt katmanı ekleyerek alanı/varlık tipini fiilen otomatik üretir hale getirdim
      LLM’ler, ayrıştırılmış bilginin doğru ayrıntı düzeyini yakalamakta temelde çok iyi değil
      İşe yarayan bir yöntem, LLM’den bir mermaid.js zihin haritası üretmesini isteyip girdiyi hiyerarşik bir ağaç halinde bölmesini sağlamak ve sonunda hangi seviyenin bilgi düğümü için uygun kök olduğunu söylemesini istemek
      Sonrasında, o düğüm içindeki bilgiyle yanıtlanabilecek soruları üretiyor, bu soru metinlerini indeksliyor ve embedding’lerini de çıkarıyorum
      Kullanıcı sorgusunu doğrudan bu sorularla saf BM25 üzerinden eşleştirmek de iyi sonuç veriyor; hibrit yaklaşım daha iyi ama fark çok büyük değil
      Sorgu anında LLM kullanmıyorsanız, embedding benzerliğini geçiş maliyet fonksiyonu yapıp kökten daha derin düğümlere hiyerarşik olarak da inebilirsiniz
    • Geçmişte benzer bir ağaç yapısını denediğimde iyi sonuçlar almıştım
      Sonunda bunun bir genellemesi olarak grafa geçmeye karar verdim
      Graf üzerinde “yürümek” için embedding benzerliğini kullanma fikrinin kilit nokta olduğunu düşünüyorum ve bunu FastGraphRAG’e de sorguya göre kenar ağırlığı verme şeklinde aktif olarak entegre ediyorum
      Farklı çözümlerin benzer tasarımlarda yakınsamasını görmek ilginç
    • “Toplama aşamasında LLM ile biraz iş yapmak” derken neyi kastettiğinizi ve amacının ne olduğunu biraz daha açarsanız iyi olur
      Sorgudan varsayımsal yanıt üretip sonra bu yanıtla embedding araması yapma fikri ilginç; bunu deneme listeme eklemek istiyorum
    • Sorgudan varsayımsal yanıt üretip bunu RAG akışında kullanmanın gerçekten işe yaradığını duymak sevindirici
      Artık korpusa göre ince ayar yapılmış bir LLM ile varsayımsal yanıt üretmenin daha da iyi çalışıp çalışmayacağını merak ediyorum
    • BM25 indeksine giren metni chunk’lara bölüyor musunuz diye merak ediyorum
      Varsayımsal yanıt oluştururken de “chunk boyutuna” uygun yanıt vermesi için prompt verip vermediğinizi öğrenmek isterim

  • Daha iyi merkezilik için PageRank kullanmak mantıklı görünüyor, ancak RAG’in muhtemelen çözülemez kusurunu, yani RAG’in neden temelde çalışmasının zor olduğunu hâlâ çözmüyor
    Tüm RAG veritabanlarının beklenenden düşük performans vermesinin nedeni, RAG’in kullanıcının istediği bilgiyi bulmak için gereken kelimeler arası ilişkileri temelde yakalayamaması
    Kulağa tuhaf gelebilir; normalde “attention” mekanizmasının bunu iyi yapması gerektiği düşünülebilir ama pratikte yeterli olmuyor
    Örneğin bir metinde, ‘Sharon’ adlı bir kişinin çeşitli fizikokimya konferanslarına katıldığı yazıyor olsun ama mesleği açıkça belirtilmemiş olsun
    “Sharon’ın mesleği nedir?” diye aradığınızda, RAG yaklaşımlarının neredeyse hiçbiri ‘meslek’, konferansa katılım ve konferans türlerini bağlayıp ‘kimyager’ sonucunu çıkaramaz
    Bu tür hata, RAG ile bilgi ararken pek çok bilgi türüne yayılmış durumda
    Sonuçta yukarıdaki gibi çözümler, SQL ya da PageRank gibi başka sorgu yöntemlerini daha fazla adımla yeniden icat ediyormuş gibi görünüyor; o noktada da vektörleştirmenin pek anlamı kalmıyor

    • Bu çıkarımı yapma işi LLM’in rolü değil mi?
      RAG bileşeninin yapması gereken, sadece büyük veri kümesinde Sharon’la ilgili metni bulup tümünü bağlam olarak LLM’e vermek
    • Aslında bu tür bir örnek, tam da bu yaklaşımın özünü oluşturuyor
      Orijinal yazıda alıntılanan HippoRAG makalesine bakarsanız, motivasyon örneği neredeyse aynı ve değerlendirme de büyük ölçüde bu tür çok adımlı soru-cevap üzerine kurulu
    • Bilgi grafiği kullanılırsa imkânsız görünmüyor
      Sharon adlı varlığı alıp, ek bağlam olarak Sharon’a yakın düğüm ve kenarları getirmek yeterli olur
      Sonrası LLM’in işi; verilen bağlamda meslek yoksa, “Verilen bağlamda Sharon’ın mesleği bulunamıyor” demeli

  • İlginç geldiği için kaydolup panoya birkaç PDF belge yüklemeyi denedim.
    Kullanım durumu, bir yapay zeka girişiminde üretimle ilgili uyumluluk belgelerini analiz etmek; bunun bize faydalı olabilmesi için hangi ölçeğe kadar çalıştığını ve maliyet modelinin nasıl olduğunu anlamamız gerekiyor.
    Müşteri başına yaklaşık 300 bin PDF var ve her ay belge kümesinin yaklaşık %10'unun değişmesi bekleniyor.
    Herhangi bir GraphRAG sisteminin belgeleri büyük ölçekte işlemesi gerekir ve S3'ü toplama mekanizması olarak kullanabiliriz, ancak sonraki noktada sistemin yeniden kullanılabilir hale gelmesine kadar olan maliyeti ve işlem süresini bilmemiz gerekiyor.

    1. İlk yükleme
    2. Düzenli güncellemeler — örneğin sistemde verilerin nasıl silindiği
    • Yardımcı olabilirim.
      Daha ayrıntılı konuşmak isterim; antonio [at] circlemind.co adresinden bana ulaşabilirseniz sevinirim.

  • İlginç; ancak faydalı bir bilgi grafiği elde etmek için alan-özgü metin külliyatının ne kadar büyük olması gerektiğini merak ediyorum.
    Aider bir süredir kod depolarının çağrı grafiğine PageRank uyguluyor.
    Önemsiz olmayan tüm kodlarda PageRank'i destekleyecek bol miktarda grafik yapısı var; bu yüzden mevcut işle ilgili proje içindeki en alakalı bağlamı bulmada çok iyi çalışıyor.
    https://aider.chat/docs/repomap.html#optimizing-the-map

    • Kısa öykülerden milyonlarca tokenlık belgelere kadar denedim ve ikisi de ilginç grafikler üretiyor gibi görünüyor.
      Daha fazla kişi kullanmaya başlayınca geri bildirim duymak isterim.
    • Aider'i severek kullanıyorum ama kod tabanı Python, JS ya da TS olsun hiç başarılı bir repo map oluşturamadım.
      Repo map'i zorla oluşturup incelemeyi mümkün kılma planınız var mı, merak ediyorum.

  • Harika.
    Grafiğin nasıl saklandığını ve sorgulandığını merak ediyorum.
    Grafik veritabanlarına aşinayım ama burada bir bağımlılık gibi görünmüyor.
    Çıkarım için sciphi triplex modelini denediniz mi, onu da merak ediyorum.
    Daha önce çıkarım yaparken aynı chunk'ı art arda birkaç kez işlediğimde sonuçlar tutarlı olmuyordu.

    • Grafik şu anda python-igraph ile saklanıyor.
      Kod tabanı, hafif bir sarmalayıcı yazıldığında herhangi bir graph DB ile kolayca entegre edilecek şekilde tasarlandı; yakın gelecekte neo4j gibi şeyleri desteklemeyi planlıyoruz.
      triplex'i henüz denemedik çünkü gpt4o-mini şimdilik yeterince hızlı ve doğruydu.
      Yalnızca varlık ve ilişki çıkarımı için değil, açıklama üretimi ve çakışma çözümü için de gpt4o-mini kullanıyoruz.
      İnce ayar yapılırsa sonuçlar kesinlikle daha iyi olacaktır.
      Grafik sorgulama, verilen sorguyla ilişkili başlangıç düğümleri kümesini bulup ardından bu düğümlerden kişiselleştirilmiş PageRank çalıştırarak diğer ilgili pasajları bulma şeklinde işliyor.
      Şu anda başlangıç düğümlerini hem tüm sorgu hem de sorgudan çıkarılan varlıklar için anlamsal aramayla seçiyoruz, ancak bu yönteme dair bazı ilginç ek özellikler de planlanıyor.

  • İyi fikir.
    Şahsen RAG için gidilmesi gereken yolun geleneksel bilgi erişimi olduğunu düşünüyorum.
    Vektör arama iyi ama yavaş ve pahalı; ayrıca insanlar bunu sihirli tozmuş gibi kullanma eğiliminde.
    Yapılandırılmamış veride iyi çalışıyor ama yapılandırılmış veride mutlaka o kadar iyi uymuyor.
    Çok iyi ayarlanmadığı sürece vektör arama, iyi ayarlanmış geleneksel sorgulardan çok daha iyi de değil.
    Yapılandırılmış veriyi yapılandırılmamış veriye dönüştürüp ardından vektör arama veya prompt engineering yapmaya çalışan pratikler gördüm; genel olarak biraz ters bir yaklaşım gibi geliyor.
    Bir ölçüde çalışıyor ama aynı sonucu elde etmenin daha akıllı yolları olma ihtimali yüksek.
    Graph RAG'in özü veri yapısından yararlanmaktır.
    Bunun SQL join mi yoksa graph DB sorgusu mu olduğu çok önemli değil.
    LLM'ye nasıl sorgulama yapılacağını öğretmekte veya mevcut arama/sorgu API'leriyle arayüz kurmasını sağlamakta da değer var.
    Sıralama çok iyi değilse bu, daha büyük bağlam boyutuyla telafi edilebilir; birden fazla sorguyla yüzlerce sonuç getirilebilir.
    Böyle ölçeklemek, vektör aramadan çok daha hızlı ve ucuz olacaktır.

  • Güzel görünüyor ama LangChain gibi başka soyutlama katmanlarından canım yandığı için aşırı basitleştirme konusunda endişeliyim.
    Aynı hataları tekrarlamamak için nasıl bir planınız var, merak ediyorum.

  • Arama ve üretim için değerlendirme metriği puanları olup olmadığını merak ediyorum.
    Örneğin KILT veya NQ veri kümeleri gibi.
    Kıyaslama veri kümeleri her şey demek değil, ama makul puanlar ve çıkarım süresi gösterebilirseniz bu, framework'ü savunmak veya mühendislerin seçim yapması açısından çok yardımcı olur.
    Serbest çalışan bir doğal dil işleme mühendisi olarak çok sayıda RAG pipeline'ı kurdum ve bunu bizzat denemeyi planlıyorum.

  • Şu anda bir Soru-Cevap chatbot'u yapıyorum ve aşağıdaki senaryoyu ele almakta zorlanıyorum.
    Kullanıcı “Az önce söylediğin önceki cümlede ne demek istedin?” diye sorduğunda, bu framework'ün doğru küçük ham bilgi alt kümesini nasıl bulup LLM'e entegre ederek alakalı bir yanıt üretebildiğini merak ediyorum.
    Harici framework'lere bağımlı olmadan bu sorunu çözmek zordu.
    https://www.reddit.com/r/LocalLLaMA/comments/1gtzdid/d_optim...
    Bu framework'ün bu sorunu nasıl çözdüğünü ve süreci nasıl basitleştirebileceğini öğrenmek isterim.

    • Birçok deneyden sonra, sohbet tarzı uygulamalarda işe yarayan tek şey son 4~5 mesajı geçirmek, mümkünse tüm konuşma geçmişini de vermek ve ardından LLM'den soruyu konuşma bağlamı içinde özetlemesini istemek oldu.
      Bu olmadan kullanıcı “2. maddeyi daha ayrıntılı açıkla” ya da “Yukarıdakine dair ayrıntılı bir örnek ver” gibi sorular sorduğunda sık sık başarısız oluyordu.
      Mevcut uygulama üç indeks tutuyor; sorgu ve geçmiş mesajlar verildikten sonra LLM'den bunu şu parçalara ayırması isteniyor:
      tam istek, BM25 için optimize edilmiş soru, anahtar kelimeler, anlamsal arama için optimize edilmiş soru.
      Sonrasında RAG ve yeniden sıralama yapılıyor, en üstteki N pasaj tüm istekle birlikte ikinci bir LLM çağrısına veriliyor.
    • Kullanıcı böyle bir soru sorarsa ajan RAG'i çağırmamalı, yalnızca konuşma geçmişiyle yanıt vermeli.
      Orkestrasyon aşamasına odaklanmanız gerekir.
      ReAct agent'lara bakabilirsiniz; bunu LangGraph veya Bedrock Agents ile kurabilirsiniz.
    • LLM'nin bilgi aramasını kullanıp kullanmamaya araç kullanımı ya da doğrudan sorgu üzerinden karar vermesini denediniz mi, merak ediyorum.