Self-Hosting Cognee: Uji Kinerja LLM

Menguji Cognee dengan LLM lokal - hasil nyata

Konten Halaman

Cognee adalah kerangka kerja Python untuk membangun grafik pengetahuan dari dokumen menggunakan LLM. Tapi apakah itu bekerja dengan model yang dihosting sendiri?

Saya mengujinya dengan beberapa LLM lokal untuk mengetahui jawabannya.

cognee memproses pdf dengan procelist

Itu adalah halaman pricelist PDF yang telah saya coba proses.

TL;DR

Cognee kemungkinan besar bekerja dengan baik dengan LLM cerdas yang memiliki ratusan miliar parameter, tetapi untuk konfigurasi RAG yang dihosting sendiri yang diharapkan secara otomatis mengekstrak data dari PDF (seperti pricelist), gagal memberikan hasil pada perangkat keras saya. Ketergantungan berat kerangka kerja pada output terstruktur membuatnya sulit bagi model lokal kecil untuk beroperasi secara andal.

Apa itu Cognee?

Cognee adalah kerangka kerja Python open-source yang dirancang untuk membangun grafik pengetahuan dari dokumen tidak terstruktur menggunakan LLM. Berbeda dengan sistem RAG tradisional yang hanya memotong dan menyematkan dokumen, Cognee berusaha menciptakan pemahaman semantik dengan mengekstrak entitas, hubungan, dan konsep ke dalam basis data graf. Pendekatan ini sejalan dengan arsitektur RAG canggih seperti GraphRAG, yang menjanjikan pencarian kontekstual yang lebih baik.

Kerangka kerja mendukung beberapa backend:

  • Basis data vektor: LanceDB (default), dengan dukungan untuk basis data vektor lainnya
  • Basis data graf: Kuzu (default), memungkinkan kueri hubungan yang kompleks
  • Pemasok LLM: OpenAI, Anthropic, Ollama, dan lainnya
  • Kerangka output terstruktur: BAML dan Instructor untuk pembuatan yang terbatas

Bagi penggemar self-hosting, kompatibilitas Cognee dengan Ollama membuatnya menarik untuk penggunaan lokal. Namun, setan berada di detailnya – seperti yang akan kita lihat, persyaratan output terstruktur menciptakan tantangan besar bagi model-model kecil.

Mengapa Output Terstruktur Penting

Cognee sangat bergantung pada output terstruktur untuk mengekstrak informasi dari dokumen dalam format yang konsisten. Saat memproses dokumen, LLM harus mengembalikan JSON yang benar-benar diformat, yang berisi entitas, hubungan, dan metadata. Inilah tempat banyak model kecil kesulitan.

Jika Anda bekerja dengan output terstruktur dalam proyek Anda sendiri, memahami batasan ini sangat penting. Tantangan yang saya alami dengan Cognee mencerminkan isu-isu yang lebih luas dalam ekosistem LLM saat bekerja dengan model lokal.

Pengaturan Konfigurasi

Berikut konfigurasi kerja saya untuk Cognee dengan Ollama. Perhatikan pengaturan kunci yang memungkinkan operasi lokal:

TELEMETRY_DISABLED=1

# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"  

# Konfigurasi LLM 
LLM_API_KEY="ollama"  
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"  
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"


# Konfigurasi Embedding
EMBEDDING_PROVIDER="ollama"  
EMBEDDING_MODEL="avr/sfr-embedding-mistral:latest"  
EMBEDDING_ENDPOINT="http://localhost:11434/api/embeddings"  
EMBEDDING_DIMENSIONS=4096  
HUGGINGFACE_TOKENIZER="Salesforce/SFR-Embedding-Mistral"  

# Konfigurasi BAML
BAML_LLM_PROVIDER="ollama"  
BAML_LLM_MODEL="gpt-oss:20b" 

BAML_LLM_ENDPOINT="http://localhost:11434/v1"


# Pengaturan Database (default)
DB_PROVIDER="sqlite"  
VECTOR_DB_PROVIDER="lancedb"  
GRAPH_DATABASE_PROVIDER="kuzu"

# Otentikasi
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

Pilihan Konfigurasi Utama

Kerangka Output Terstruktur: Saya menguji BAML, yang memberikan kontrol yang lebih baik terhadap skema output dibandingkan dengan pemicuan dasar. BAML dirancang khusus untuk output LLM terstruktur, membuatnya cocok alami untuk tugas ekstraksi graf pengetahuan.

Pemasok LLM: Menggunakan titik akhir API OpenAI-kompatibel Ollama (/v1) memungkinkan Cognee memperlakukannya seperti layanan OpenAI lainnya.

Model Embedding: Model SFR-Embedding-Mistral (4096 dimensi) memberikan embedding berkualitas tinggi. Untuk informasi lebih lanjut tentang pemilihan model embedding dan kinerjanya, model embedding Qwen3 menawarkan alternatif yang sangat baik dengan kemampuan multibahasa yang kuat.

Basis Data: SQLite untuk metadata, LanceDB untuk vektor, dan Kuzu untuk graf pengetahuan mempertahankan segala sesuatu lokal tanpa ketergantungan eksternal.

Menginstal Cognee

Instalasi sangat sederhana menggunakan uv (atau pip). Saya merekomendasikan menggunakan uv untuk resolusi dependensi yang lebih cepat:

uv venv && source .venv/bin/activate
uv pip install cognee[ollama]
uv pip install cognee[baml]
uv pip install cognee[instructor]

uv sync --extra scraping
uv run playwright install
sudo apt-get install libavif16

Ekstra [ollama], [baml], dan [instructor] menginstal dependensi yang diperlukan untuk operasi LLM lokal dan output terstruktur. Ekstra scraping menambahkan kemampuan pengambilan data web, sementara Playwright memungkinkan pemrosesan halaman yang di-render JavaScript.

Contoh Kode dan Penggunaan

Berikut alur kerja dasar untuk memproses dokumen dengan Cognee. Pertama, kita tambahkan dokumen dan bangun graf pengetahuan:

msy-add.py:

import cognee
import asyncio

async def main():

    # Buat ulang untuk Cognee -- reset data dan status sistem
    await cognee.prune.prune_data()
    await cognee.prune.prune_system(metadata=True)
    
    # Tambahkan konten contoh
    await cognee.add(
        "/home/rg/prj/prices/msy_parts_price_20251224.pdf",
        node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
    )
    
    # Proses dengan LLM untuk membangun graf pengetahuan
    await cognee.cognify()

if __name__ == '__main__':
    asyncio.run(main())

Parameter node_set memberikan tag semantik yang membantu mengkategorikan dokumen dalam graf pengetahuan. Metode cognify() adalah tempat ajaib (atau masalah) terjadi – ia mengirimkan potongan dokumen ke LLM untuk ekstraksi entitas dan hubungan.

msy-search.py:

import cognee
import asyncio

async def main():

    # Cari graf pengetahuan
    results = await cognee.search(
        query_text="Apa produk yang ada dalam daftar harga?"
#       query_text="Apa rata-rata harga untuk RAM 32GB (2x16GB modul)?"
    )
    
    # Cetak
    for result in results:
        print(result)

if __name__ == '__main__':
    asyncio.run(main())

Berbeda dengan pencarian vektor tradisional dalam sistem RAG, Cognee menginterogasi graf pengetahuan, secara teoretis memungkinkan pencarian berbasis hubungan yang lebih canggih. Ini mirip dengan cara arsitektur RAG canggih bekerja, tetapi memerlukan konstruksi graf awal untuk berhasil.

Hasil Uji Coba: Kinerja LLM

Saya menguji Cognee dengan kasus penggunaan nyata: mengekstrak informasi produk dari PDF daftar harga komponen komputer. Ini tampak seperti skenario ideal – data terstruktur dalam format tabel. Berikut yang terjadi dengan setiap model:

Model yang Dites

1. gpt-oss:20b (20 miliar parameter)

  • Hasil: Gagal dengan kesalahan kode karakter
  • Masalah: Menghasilkan output terstruktur yang tidak benar dengan kode karakter yang salah
  • Catatan: Meskipun dirancang khusus untuk kompatibilitas open-source, tidak bisa mempertahankan format JSON yang konsisten

2. qwen3:14b (14 miliar parameter)

  • Hasil: Gagal menghasilkan output terstruktur
  • Masalah: Model akan menghasilkan teks tetapi bukan dalam skema JSON yang diperlukan
  • Catatan: Model Qwen biasanya bekerja baik, tetapi tugas ini melampaui kemampuan output terstruktur model tersebut

3. deepseek-r1:14b (14 miliar parameter)

  • Hasil: Gagal menghasilkan output terstruktur
  • Masalah: Mirip dengan qwen3, tidak bisa mematuhi persyaratan skema BAML
  • Catatan: Kemampuan penalaran tidak membantu kepatuhan format

4. devstral:24b (24 miliar parameter)

  • Hasil: Gagal menghasilkan output terstruktur
  • Masalah: Meskipun dengan lebih banyak parameter, tidak bisa menghasilkan JSON yang valid secara konsisten
  • Catatan: Model coding khusus masih kesulitan dengan kepatuhan skema yang ketat

5. ministral-3:14b (14 miliar parameter)

  • Hasil: Gagal menghasilkan output terstruktur
  • Masalah: Model yang lebih kecil Mistral tidak bisa menangani permintaan output terstruktur

6. qwen3-vl:30b-a3b-instruct (30 miliar parameter)

  • Hasil: Gagal menghasilkan output terstruktur
  • Masalah: Kemampuan visi tidak membantu ekstraksi tabel PDF dalam konteks ini

7. gpt-oss:120b (120 miliar parameter)

  • Hasil: Tidak menyelesaikan pemrosesan setelah lebih dari 2 jam
  • Perangkat Keras: Konfigurasi GPU konsumen
  • Masalah: Model terlalu besar untuk penggunaan self-hosted yang praktis, meskipun mungkin akhirnya berhasil

Temuan Utama

Batasan Ukuran Potongan: Cognee menggunakan potongan 4k token saat memproses dokumen dengan Ollama. Untuk dokumen yang kompleks atau model dengan jendela konteks yang lebih besar, ini terasa terlalu membatasi. Kerangka kerja tidak menyediakan cara mudah untuk menyesuaikan parameter ini.

Persyaratan Output Terstruktur: Masalah utamanya bukan kecerdasan model, tetapi kepatuhan format. Model-model ini dapat memahami konten, tetapi mempertahankan skema JSON yang konsisten selama proses ekstraksi terbukti menantang. Ini sejalan dengan tantangan yang lebih luas dalam mendapatkan model lokal untuk menghormati batasan output.

Pertimbangan Perangkat Keras: Bahkan ketika model yang cukup besar mungkin bekerja (seperti gpt-oss:120b), kebutuhan perangkat keras membuatnya tidak praktis untuk sebagian besar skenario self-hosting. Anda akan membutuhkan memori GPU dan daya pemrosesan yang signifikan.

Perbandingan dengan Praktik Terbaik Output Terstruktur

Pengalaman ini memperkuat pelajaran dari bekerja dengan output terstruktur di berbagai pemasok LLM. API komersial dari OpenAI, Anthropic, dan Google sering memiliki mekanisme bawaan untuk memaksa skema output, sementara model lokal memerlukan pendekatan yang lebih canggih seperti sampling berbasis tata bahasa atau beberapa validasi ulang.

Untuk analisis yang lebih dalam tentang memilih LLM yang tepat untuk Cognee di Ollama, termasuk perbandingan rinci tentang ukuran model yang berbeda dan karakteristik kinerjanya, tersedia panduan menyeluruh yang dapat membantu Anda membuat keputusan yang informasional.

Pendekatan Alternatif untuk RAG yang Dihosting Sendiri

Jika Anda terikat pada self-hosting dan perlu mengekstrak data terstruktur dari dokumen, pertimbangkan alternatif berikut:

1. RAG Tradisional dengan Ekstraksi Sederhana

Alih-alih membangun graf pengetahuan kompleks terlebih dahulu, gunakan RAG tradisional dengan pemotongan dokumen dan pencarian vektor. Untuk ekstraksi data terstruktur:

  • Parse tabel secara langsung menggunakan library seperti pdfplumber atau tabula-py
  • Gunakan prompt sederhana yang tidak memerlukan kepatuhan skema yang ketat
  • Implementasikan validasi pasca-pemrosesan dalam Python, bukan mengandalkan format output LLM

2. Model Embedding Khusus

Kualitas embedding Anda secara signifikan memengaruhi kinerja pencarian. Pertimbangkan model embedding berkualitas tinggi yang bekerja baik secara lokal. Model embedding modern seperti penawaran Qwen3 memberikan dukungan multibahasa yang sangat baik dan dapat meningkatkan secara dramatis akurasi sistem RAG Anda.

3. Reranking untuk Hasil yang Lebih Baik

Meskipun dengan arsitektur RAG sederhana, menambahkan langkah reranking dapat secara signifikan meningkatkan hasil. Setelah pencarian vektor awal, model reranking dapat menilai relevansi dengan lebih baik. Pendekatan dua tahap ini sering mengungguli sistem tunggal yang lebih kompleks, terutama saat bekerja dengan perangkat keras yang terbatas.

4. Strategi Pencarian Hibrida

Menggabungkan pencarian vektor dengan pencarian kata kunci tradisional (BM25) sering menghasilkan hasil yang lebih baik daripada salah satunya. Banyak basis data vektor modern mendukung pencarian hibrida secara langsung.

5. Pertimbangkan Alternatif Basis Data Vektor

Jika Anda membangun sistem RAG dari awal, evaluasi berbagai basis data vektor berdasarkan kebutuhan Anda. Pilihan berkisar dari basis data tersemat ringan hingga sistem terdistribusi yang dirancang untuk skala produksi.

Pertimbangan Penempatan Docker

Untuk penempatan self-hosting produksi, meng-containerisasi setup RAG Anda menyederhanakan penempatan dan skalabilitas. Saat menjalankan Cognee atau kerangka kerja serupa dengan Ollama:

# Jalankan Ollama dalam kontainer
docker run -d --gpus=all -v ollama:/root/.ollama -p 114线:11434 --name ollama ollama/ollama

# Tarik model Anda
docker exec -it ollama ollama pull gpt-oss:20b

# Konfigurasikan Cognee untuk terhubung ke titik akhir kontainer

Pastikan untuk mengatur ulang GPU dan pemasangan volume dengan benar untuk keberlanjutan model.

Pelajaran yang Dipelajari

1. Sesuaikan Alat dengan Perangkat Keras: Cognee dirancang untuk LLM skala awan. Jika Anda self-hosting pada perangkat keras konsumen, arsitektur yang lebih sederhana mungkin lebih praktis.

2. Output Terstruktur Sulit: Mendapatkan kepatuhan skema yang konsisten dari LLM lokal tetap menantang. Jika aplikasi Anda sangat bergantung pada output terstruktur, gunakan API komersial atau implementasikan validasi dan logika ulang yang robust.

3. Uji Awal: Sebelum mengkomitmen pada kerangka kerja, uji dengan kasus penggunaan dan perangkat keras spesifik Anda. Yang bekerja dalam demo mungkin tidak bekerja dalam skala atau dengan dokumen Anda.

4. Pertimbangkan Pendekatan Hibrida: Gunakan API komersial untuk tugas ekstraksi yang kompleks dan model lokal untuk pertanyaan yang lebih sederhana untuk menyeimbangkan biaya dan kemampuan.

Bacaan Terkait

Output Terstruktur dengan LLM

Memahami output terstruktur sangat penting untuk kerangka kerja seperti Cognee. Artikel-artikel berikut membahas secara mendalam cara mendapatkan respons yang konsisten dan mematuhi skema dari LLM:

Arsitektur dan Implementasi RAG

Untuk pendekatan alternatif atau komplementer untuk ekstraksi pengetahuan dan pencarian:

Embedding dan Reranking

Meningkatkan kualitas pencarian melalui embedding dan reranking yang lebih baik:

Alat dan Sumber Daya

Sumber Daya Eksternal