HN Rilis: FastGraphRAG – Teknik RAG yang ditingkatkan dengan memanfaatkan PageRank tradisional

 (github.com/circlemind-ai)
1 poin oleh GN⁺ 2024-11-19 | 1 komentar | Bagikan ke WhatsApp
  • Fast GraphRAG adalah framework GraphRAG yang disederhanakan untuk workflow pencarian berbasis agen yang dapat diinterpretasikan dan berpresisi tinggi, dengan fokus pada menambahkan RAG tingkat lanjut ke pipeline pencarian tanpa harus membangun workflow agen yang kompleks secara langsung
  • Membuat knowledge graph menjadi bentuk yang dapat dijelajahi manusia, memungkinkan kueri, visualisasi, dan pembaruan, serta membuat dan menyempurnakan graph secara otomatis sesuai kebutuhan domain dan ontologi
  • Untuk respons kueri, menggunakan penjelajahan graph berbasis personalized PageRank guna menemukan informasi yang relevan, dan README menautkan paper HippoRAG sebagai gambaran umum pendekatan ini
  • Dalam contoh biaya untuk The Wizard of Oz, fast-graphrag disebutkan berbiaya $0.08, sementara graphrag $0.48; disebutkan bahwa penghematan biaya 6x ini makin membaik seiring bertambahnya ukuran data dan jumlah penyisipan
  • Berjalan di Python 3.10.1 ke atas, mendukung instalasi dari source dan PyPI, lalu setelah mengatur OpenAI API key, dapat melakukan penyisipan dokumen dan kueri serta mempertahankan pengetahuan secara otomatis di direktori kerja yang sama

Framework pencarian yang disediakan Fast GraphRAG

  • Fast GraphRAG adalah framework GraphRAG yang bertujuan menghadirkan pengetahuan yang dapat diinterpretasikan dan di-debug
  • Graph menyediakan pengetahuan dalam bentuk yang dapat dijelajahi manusia, dan mendukung tugas berikut
    • Kueri
    • Visualisasi
    • Pembaruan
  • Fokusnya adalah menyediakan kemampuan RAG tingkat lanjut sambil mengurangi beban untuk membangun dan merancang workflow agen secara langsung

Fitur utama

  • Dirancang agar dapat dijalankan dalam skala besar dengan cepat dan berbiaya rendah, dengan arah mengurangi kebutuhan resource atau biaya yang berat
  • Mendukung data dinamis dengan membuat dan menyempurnakan graph secara otomatis sesuai kebutuhan domain dan ontologi
  • Mendukung pembaruan inkremental saat data berubah, sehingga memungkinkan pembaruan real-time
  • Menyediakan penjelajahan cerdas yang meningkatkan akurasi dan keandalan dengan memanfaatkan penjelajahan graph berbasis PageRank
  • Secara keseluruhan bersifat asinkron, dan menargetkan workflow yang tangguh serta dapat diprediksi melalui dukungan tipe yang lengkap

Contoh biaya

  • Dalam contoh yang menggunakan The Wizard of Oz, biaya fast-graphrag ditampilkan sebesar $0.08, sedangkan biaya graphrag sebesar $0.48
  • README menjelaskannya sebagai penghematan biaya 6x, dan menyebutkan bahwa efek penghematan akan makin membaik ketika ukuran data dan jumlah penyisipan meningkat

Alur instalasi dan eksekusi

  • Metode instalasi yang direkomendasikan terbagi menjadi instalasi dari source untuk performa dan instalasi PyPI untuk stabilitas
    • Instalasi dari source: clone repositori lalu jalankan poetry install
    • Instalasi PyPI: pip install fast-graphrag
  • Contoh quick start terlebih dahulu mengatur variabel lingkungan OPENAI_API_KEY
  • Setelah mengunduh teks A Christmas Carol, kode Python menginisialisasi GraphRAG
  • Inisialisasi contoh mencakup nilai berikut
    • working_dir="./book_example"
    • domain yang menganalisis karakter, interaksi, tempat, dan hubungan dalam cerita
    • daftar kueri contoh
    • tipe entitas ["Character", "Animal", "Place", "Object", "Activity", "Event"]
  • Dokumen disisipkan dengan grag.insert(f.read()), dan hasil kueri dicetak dengan grag.query("Who is Scrooge?").response
  • Jika diinisialisasi kembali di direktori kerja yang sama, pengetahuan dipertahankan secara otomatis
  • Untuk mengontrol jumlah tugas pemrosesan LLM secara bersamaan, misalnya saat menggunakan model lokal, variabel lingkungan seperti CONCURRENT_TASK_LIMIT=8 dapat diatur secara opsional

Contoh dan opsi konfigurasi

  • Folder examples menyediakan tutorial kasus penggunaan umum library ini
  • custom_llm.py adalah contoh sederhana untuk mengatur model bahasa dan embedder yang kompatibel dengan OpenAI API secara berbeda
  • checkpointing.ipynb membahas cara menggunakan checkpoint untuk menghindari kerusakan data yang tidak dapat dibalik
  • query_parameters.ipynb membahas berbagai parameter kueri, dan menunjukkan cara menyertakan referensi informasi yang digunakan dalam jawaban dengan with_references=True

Filosofi desain dan metode penjelajahan

  • Tujuannya adalah meningkatkan jumlah aplikasi GenAI yang berhasil; untuk itu, mereka membuat alat memori dan data yang memungkinkan aplikasi LLM memanfaatkan pipeline pencarian khusus tanpa harus menyiapkan dan memelihara workflow agen yang kompleks
  • Fast GraphRAG menjelajahi graph dengan algoritme personalized PageRank untuk menemukan informasi yang paling relevan dalam menjawab kueri saat ini
  • Sebagai gambaran umum mengapa pendekatan ini bekerja, paper HippoRAG disajikan sebagai referensi

Open source dan layanan terkelola

  • Repositori ini tersedia dengan MIT License, dan detailnya ada di LICENSE.txt
  • Mereka menyediakan layanan terkelola sebagai cara untuk mulai dengan cepat dan andal
  • Layanan terkelola menggratiskan 100 request pertama setiap bulan, lalu setelah itu dikenakan biaya berbasis penggunaan
  • Untuk mempelajari lebih lanjut tentang layanan terkelola, Anda dapat menjadwalkan demo atau melihat docs
  • Panduan kontribusi tersedia di CONTRIBUTING.md, dan pertanyaan dapat diajukan di Discord

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-19
Komentar Hacker News

  • Selain PageRank, ada beberapa metrik sentralitas menarik yang dapat memengaruhi RAG pada data terstruktur
    Salah satunya, Triangle Centrality, menghitung sentralitas dengan menghitung segitiga di sekitar node, berdasarkan konsep bahwa segitiga menutup relasi dengan kuat, sementara koneksi terbuka mengambil bobot dari pusat dan mengencerkan sentralitas
    https://arxiv.org/abs/2105.00110
    Makalahnya mengatakan ini lebih efisien daripada sentralitas lain seperti PageRank, tetapi dalam riset yang menggunakan GraphBLAS, pada berbagai graf sparse hingga skala 1,8 miliar edge, TC lebih lambat daripada implementasi sparse PageRank kami
    Namun, seiring graf makin besar, TC tampaknya diskalakan lebih baik, dan kemungkinan besar lebih efisien pada wilayah edge berskala triliunan
    https://fossies.org/linux/SuiteSparse/GraphBLAS/Doc/The_Grap...

    • Di sini node/edge hanya berskala jutaan, jadi efisiensi bukan masalah besar
      Bagaimanapun, pembuatan jawaban akan dibatasi oleh bagian yang diurai oleh LLM
      PageRank adalah langkah pertama, tetapi saya juga ingin menguji alternatif yang lebih akurat
      Di sini digunakan Personalized PageRank, sehingga bobot awal diberikan pada sekumpulan node tertentu; saya penasaran apakah Triangle Centrality juga mendukung hal ini
      Selain itu, karena bobot edge juga diperhatikan, saya ingin tahu apakah bagian itu juga memungkinkan
    • Penasaran apakah sudah mencoba Authority Rank sebagai pengganti PageRank
      https://link.springer.com/content/pdf/10.1007/978-3-030-6097...

  • Saya sudah cukup banyak bekerja di area ini, dan ada beberapa hal yang saya pelajari

    1. Jika bisa melakukan sedikit pekerjaan dengan LLM pada saat ingest, pencarian leksikal berbasis BM25 saja sudah bisa menghasilkan hasil yang sangat relevan
    2. Embedding hanya bekerja dengan baik ketika ukuran kueri kira-kira berada pada orde yang sama dengan objek yang dimasukkan ke penyimpanan embedding
    3. Jika LLM diminta menghasilkan jawaban hipotetis dari kueri, lalu jawaban hipotetis itu dipakai untuk pencarian embedding, hasilnya sangat bagus
      Saya menggabungkan ketiganya untuk membuat tahap dekomposisi/ekstraksi pengetahuan serupa, lalu menambahkan meta-prompter agar tipe domain/entitas pada dasarnya dibuat otomatis
      Pada dasarnya LLM tidak pandai menentukan tingkat granularitas yang tepat untuk pengetahuan yang sudah dipecah
      Salah satu trik adalah meminta LLM mengeluarkan mind map mermaid.js untuk membagi input menjadi pohon hierarkis, lalu pada bagian akhir menyebutkan level mana yang menjadi root yang tepat untuk node pengetahuan
      Setelah itu, buat pertanyaan-pertanyaan yang dapat dijawab dengan pengetahuan di dalam node tersebut, lalu indeks dan embedding teks pertanyaan ini
      Mencocokkan kueri pengguna secara langsung dengan pertanyaan-pertanyaan ini menggunakan BM25 murni pun memberi hasil yang baik; pendekatan hybrid lebih baik, tetapi selisihnya tidak terlalu besar
      Jika tidak memakai LLM pada saat kueri, embedding similarity juga bisa dijadikan fungsi biaya traversal untuk turun secara hierarkis dari root ke node yang lebih dalam
    • Dulu ketika bereksperimen dengan struktur pohon yang mirip, hasilnya bagus
      Pada akhirnya saya memutuskan pindah ke graf sebagai generalisasi dari pohon
      Saya melihat konsep memakai embedding similarity untuk “berjalan” di graf sebagai inti, dan di FastGraphRAG ini juga sedang diintegrasikan secara aktif lewat pemberian bobot edge berdasarkan kueri
      Menarik melihat berbagai solusi berkonvergensi ke desain yang mirip
    • Akan bagus jika bisa menjelaskan lebih lanjut apa yang dimaksud dengan “sedikit pekerjaan dengan LLM pada saat ingest” dan apa tujuannya
      Ide membuat jawaban hipotetis dari kueri lalu melakukan pencarian embedding dengan jawaban itu menarik, dan saya akan menambahkannya ke daftar eksperimen
    • Senang mendengar bahwa cara membuat jawaban hipotetis dari kueri lalu memakainya dalam alur RAG benar-benar berhasil
      Sekarang saya penasaran apakah membuat jawaban hipotetis dengan LLM yang di-fine-tune sesuai korpus akan bekerja lebih baik
    • Penasaran apakah teks yang masuk ke indeks BM25 dibagi menjadi chunk
      Saya juga ingin tahu apakah saat membuat jawaban hipotetis, prompt-nya meminta respons yang disesuaikan dengan “ukuran chunk”

  • Menggunakan PageRank untuk sentralitas yang lebih baik tampaknya bagus, tetapi tetap tidak menyelesaikan cacat RAG yang mungkin tidak bisa diatasi, yaitu alasan mendasar mengapa RAG sulit bekerja
    Alasan semua DB RAG berkinerja di bawah ekspektasi adalah karena RAG secara fundamental tidak dapat menemukan relasi antarkata yang diperlukan untuk menemukan informasi yang diinginkan pengguna
    Mungkin terdengar aneh, dan orang mungkin berpikir mekanisme “attention” semestinya pandai melakukan hal seperti ini, tetapi kenyataannya tidak cukup
    Misalnya, katakanlah dalam sebuah tulisan ada informasi bahwa seseorang bernama ‘Sharon’ menghadiri beberapa konferensi kimia fisik, tetapi pekerjaannya tidak disebutkan secara eksplisit
    Jika mencari “Apa pekerjaan Sharon?”, hampir semua pendekatan RAG kemungkinan besar tidak akan bisa menghubungkan ‘pekerjaan’, kehadiran di konferensi, dan jenis konferensinya untuk menyimpulkan ‘ahli kimia’
    Kesalahan seperti ini tersebar di berbagai jenis informasi saat mengambil informasi dengan RAG
    Pada akhirnya solusi seperti di atas terlihat seperti menciptakan kembali metode kueri lain seperti SQL dan PageRank dalam lebih banyak tahap, dan pada titik itu vektorisasi tidak terlalu bermakna

    • Bukankah inferensi itu peran LLM?
      Komponen RAG cukup menemukan tulisan terkait Sharon dari dataset besar dan menyerahkan semuanya sebagai konteks ke LLM
    • Justru contoh seperti ini adalah inti dari pendekatan ini
      Jika melihat makalah HippoRAG yang dikutip di artikel asli, contoh motivasinya hampir sama, dan evaluasinya juga sebagian besar disesuaikan untuk tanya jawab multi-hop semacam ini
    • Dengan knowledge graph, ini tampaknya bukan hal yang mustahil
      Ambil entitas bernama Sharon, lalu terima node dan edge yang dekat dengan Sharon sebagai konteks tambahan
      Selanjutnya adalah peran LLM, dan jika tidak ada pekerjaan dalam konteks yang diberikan, ia seharusnya memberi tahu “pekerjaan Sharon tidak dapat ditemukan dalam konteks yang diberikan”

  • Karena tertarik, saya mendaftar dan mencoba mengunggah beberapa dokumen PDF ke dashboard
    Use case-nya adalah menganalisis dokumen kepatuhan terkait manufaktur di sebuah startup AI, dan agar ini berguna bagi kami, kami perlu memahami sampai skala berapa ini bisa berjalan dan seperti apa model biayanya
    Ada sekitar 300 ribu PDF per klien, dan kami memperkirakan sekitar 10% dari kumpulan dokumen berubah setiap bulan
    Sistem GraphRAG apa pun harus memproses dokumen dalam skala besar, dan meskipun S3 bisa digunakan sebagai mekanisme ingest, kami perlu tahu biaya dan waktu pemrosesan sampai sistem siap digunakan pada titik berikut

    1. Pemuatan awal
    2. Pembaruan berkala — misalnya bagaimana sistem menghapus data
    • Sepertinya kami bisa membantu
      Saya ingin membahas lebih detail, jadi silakan hubungi antonio [at] circlemind.co

  • Menarik, tetapi saya penasaran seberapa besar korpus teks khusus domain yang dibutuhkan untuk mendapatkan knowledge graph yang berguna
    Aider sudah sejak lama menerapkan PageRank pada call graph repositori kode
    Semua kode yang tidak sepele punya banyak struktur graf untuk mendukung PageRank, sehingga ini bekerja sangat baik untuk menemukan konteks paling relevan di dalam proyek terkait pekerjaan saat ini
    https://aider.chat/docs/repomap.html#optimizing-the-map

    • Saya sudah mencobanya dari novel pendek sampai dokumen utuh berukuran jutaan token, dan keduanya tampaknya menghasilkan graf yang menarik
      Saya ingin mendengar masukan ketika lebih banyak orang mulai mencobanya
    • Saya memakai Aider dengan baik, tetapi belum pernah berhasil membuat repo map, entah codebase-nya Python, JS, atau TS
      Saya penasaran apakah ada rencana untuk memungkinkan pembuatan repo map secara paksa dan memeriksanya

  • Keren
    Saya penasaran bagaimana graf disimpan dan di-query
    Saya familier dengan database graf, tetapi sepertinya itu bukan dependensi
    Saya juga penasaran apakah untuk ekstraksi sudah mencoba model sciphi triplex
    Ketika dulu saya mencoba ekstraksi, menjalankan ekstraksi pada chunk yang sama beberapa kali berturut-turut menghasilkan output yang tidak konsisten

    • Graf saat ini disimpan dengan python-igraph
      Codebase-nya dirancang agar mudah mengintegrasikan database graf apa pun dengan menulis wrapper ringan, dan dalam waktu dekat kami berencana mendukung hal-hal seperti neo4j
      triplex belum kami coba, karena gpt4o-mini saat ini sudah cukup cepat dan akurat
      Kami memakai gpt4o-mini bukan hanya untuk ekstraksi entitas dan relasi, tetapi juga untuk pembuatan deskripsi dan penyelesaian konflik
      Fine-tuning pasti akan membuat hasilnya lebih baik
      Query graf dilakukan dengan menemukan kumpulan node awal yang relevan dengan query yang diberikan, lalu menjalankan PageRank terpersonalisasi dari node-node tersebut untuk menemukan kutipan relevan lainnya
      Saat ini kami memilih node awal lewat pencarian semantik untuk keseluruhan query maupun entitas yang diekstrak dari query, tetapi kami juga merencanakan beberapa tambahan menarik untuk pendekatan ini

  • Ide bagus
    Secara pribadi, menurut saya information retrieval tradisional adalah arah yang tepat untuk RAG
    Vector search bagus, tetapi lambat dan mahal, dan orang cenderung memakainya seperti bubuk ajaib
    Ini bekerja baik untuk data tak terstruktur, tetapi belum tentu cocok untuk data terstruktur
    Kecuali jika dituning dengan sangat baik, vector search juga tidak jauh lebih baik daripada query tradisional yang dituning dengan baik
    Saya pernah melihat praktik mengubah data terstruktur menjadi data tak terstruktur lalu melakukan vector search atau prompt engineering, dan secara keseluruhan rasanya agak terbalik
    Memang bisa bekerja sampai batas tertentu, tetapi kemungkinan besar ada cara yang lebih cerdas untuk mendapatkan hasil yang sama
    Inti dari Graph RAG adalah memanfaatkan struktur data
    Tidak terlalu penting apakah itu SQL join atau query database graf
    Mengajari LLM cara melakukan query, atau membuatnya berinteraksi dengan API pencarian/query yang sudah ada, juga akan bernilai
    Ranking yang kurang bagus bisa dikompensasi dengan ukuran konteks yang lebih besar, dan dengan mengambil ratusan hasil atau lebih lewat beberapa query
    Cara penskalaan seperti itu akan jauh lebih cepat dan murah daripada vector search

  • Terlihat bagus, tetapi karena pernah kena masalah dengan lapisan abstraksi lain seperti LangChain, saya khawatir soal penyederhanaan berlebihan
    Saya penasaran bagaimana rencana kalian agar tidak mengulangi kesalahan yang sama

  • Saya penasaran apakah ada skor metrik evaluasi untuk retrieval dan generation
    Misalnya dataset seperti KILT atau NQ
    Dataset benchmark bukan segalanya, tetapi menunjukkan skor yang cukup baik dan waktu inferensi akan sangat membantu untuk meyakinkan orang memakai framework ini atau membantu engineer memilihnya
    Sebagai engineer pemrosesan bahasa alami freelance, saya sudah banyak membuat pipeline RAG, dan saya berencana mencoba ini langsung

  • Saat ini saya sedang membuat chatbot Q&A dan mengalami kesulitan menangani skenario berikut
    Ketika pengguna bertanya, “apa maksudmu di kalimat sebelumnya yang baru saja kamu katakan?”, saya penasaran bagaimana framework ini bisa mengambil subset kecil pengetahuan mentah yang tepat dan mengintegrasikannya ke LLM untuk menghasilkan respons yang relevan
    Saya merasa sulit menyelesaikan masalah ini tanpa bergantung pada framework eksternal
    https://www.reddit.com/r/LocalLLaMA/comments/1gtzdid/d_optim...
    Saya ingin tahu bagaimana framework ini menyelesaikan masalah tersebut dan menyederhanakan prosesnya

    • Setelah berbagai eksperimen, satu-satunya cara yang berhasil dengan baik di aplikasi bergaya chat adalah meneruskan 4–5 pesan terakhir, dan jika memungkinkan seluruh riwayat percakapan, lalu meminta LLM merangkum pertanyaan dalam konteks percakapan
      Tanpa ini, sistem sering gagal ketika pengguna bertanya seperti “jelaskan lebih detail poin nomor 2” atau “beri contoh rinci dari hal di atas”
      Implementasi saat ini memakai tiga indeks, lalu memberikan query dan pesan sebelumnya kepada LLM untuk dipecah menjadi hal berikut
      Permintaan lengkap, pertanyaan yang dioptimalkan untuk BM25, kata kunci, pertanyaan yang dioptimalkan untuk pencarian semantik
      Setelah itu dilakukan RAG dan re-ranking, lalu N kutipan teratas diteruskan bersama permintaan lengkap ke panggilan LLM kedua
    • Jika pengguna mengajukan pertanyaan seperti itu, agen seharusnya tidak memanggil RAG dan cukup menjawab hanya dengan riwayat percakapan
      Anda perlu berfokus pada tahap orkestrasi
      Cari tahu tentang agen ReAct; itu bisa dibuat dengan LangGraph atau Bedrock Agents
    • Saya penasaran apakah Anda sudah mencoba membiarkan LLM memutuskan apakah perlu menggunakan pencarian pengetahuan melalui penggunaan tool atau query langsung