Penjelasan RAGFlow: Bangun Aplikasi RAG untuk Produksi

Berapa kali Anda membangun demo RAG yang berjalan mulus pada beberapa PDF bersih, namun tak mampu menjawab apa pun dari dokumen perusahaan yang sebenarnya?

Biasanya, tabel jadi gepeng, halaman hasil pindai menghilang, slide deck kehilangan judul bagiannya, dan logika chunking memisahkan header bagian dari isinya. Sistem RAG untuk produksi jauh berbeda dengan sekadar LLM plus basis data vektor. Anda membutuhkan parsing dokumen, strategi chunking, retrieval hibrida, reranking, pelacakan sitasi, orkestrasi agen, dan setengah lusin komponen lain yang harus Anda konfigurasikan sendiri.

RAGFlow adalah platform open-source yang menggabungkan semua komponen itu dalam satu tumpukan. Ia menangani parsing dokumen mendalam, chunking berbasis templat, retrieval hibrida, alur kerja agen, dan integrasi MCP di balik satu UI dan API, sehingga Anda bisa fokus pada basis pengetahuan dan tidak pada hal lain.

Dalam artikel ini, saya akan menjelaskan cara kerja RAGFlow di balik layar, seperti apa arsitekturnya, bagaimana perbandingannya dengan LangChain dan LlamaIndex, serta cara men-deploy-nya.

Jika Anda butuh penyegar mengenai cara kerja RAG, daftar ke kursus Retrieval Augmented Generation (RAG) dengan LangChain kami - Anda akan memahami dasarnya dalam satu sore.

Apa Itu RAGFlow?

RAGFlow adalah mesin RAG open-source buatan InfiniFlow yang dirilis di bawah lisensi Apache 2.0 pada April 2024.

Rancangan ini ditujukan untuk aplikasi AI tingkat produksi, di mana kualitas retrieval menentukan berhasil atau tidaknya aplikasi. Fokus proyek ini adalah pemahaman dokumen mendalam, artinya parsing dan chunking diperlakukan sebagai fondasi bagi semua langkah berikutnya. Jika PDF, spreadsheet, dan slide deck Anda berantakan, tidak ada reranker atau LLM yang lebih besar yang bisa membantu - Anda harus memperbaiki kualitas dokumennya terlebih dahulu.

Yang membedakan RAGFlow dari kebanyakan alat RAG adalah sifatnya sebagai full stack. Anda mendapatkan parsing dokumen, chunking berbasis templat, retrieval hibrida, reranking, pelacakan sitasi, pembuat alur kerja agen, dan dukungan MCP dalam satu sistem. Anda tidak perlu memilih basis data vektor, mengonfigurasi parser, menambahkan reranker, dan membangun UI di atasnya - semuanya sudah tersedia di balik satu antarmuka web dan API.

Itu membuat RAGFlow lebih mirip platform daripada framework.

Cara Kerja RAGFlow

RAGFlow mengikuti pipeline RAG standar, tetapi setiap langkahnya adalah komponen yang bisa Anda konfigurasikan, alih-alih kode yang harus Anda tulis.

Berikut yang terjadi sejak Anda mengunggah dokumen hingga LLM mengirimkan jawaban kembali:

1. Ingest dokumen: Anda mengunggah file atau menghubungkan sumber data. RAGFlow menerima PDF, file Word, lembar Excel, deck PowerPoint, Markdown, HTML, gambar, dan salinan hasil pindai. Mulai v0.25, Anda juga dapat menyinkronkan data dari Confluence, S3, Notion, Discord, dan Google Drive.
2. Parse dan strukturkan konten: Mesin DeepDoc membaca setiap file dengan OCR, pengenalan struktur tabel, dan pengenalan tata letak. Hasilnya adalah konten terstruktur dengan metadata tentang judul, tabel, gambar, dan urutan baca.
3. Hasilkan embedding: RAGFlow memproses setiap chunk melalui model embedding yang Anda pilih di konfigurasi. Anda bisa menggunakan OpenAI, Cohere, Voyage, model lokal, atau opsi lain yang didukung.
4. Indeks pengetahuan: Chunk dan vektor dimasukkan ke mesin dokumen. Elasticsearch adalah default, tetapi Anda dapat beralih ke Infinity, yaitu basis data buatan InfiniFlow untuk pencarian hibrida.
5. Ambil konteks relevan: Saat ada kueri masuk, RAGFlow menjalankan pencarian vektor, pencarian kata kunci BM25, dan reranking secara bersamaan. Anda mendapatkan chunk teratas dengan sitasi kembali ke dokumen sumber.
6. Hasilkan jawaban dengan LLM: Chunk yang diambil dimasukkan ke prompt, LLM menulis jawaban, dan RAGFlow melampirkan sitasi agar pengguna bisa menelusuri setiap klaim kembali ke bagian sumbernya.

Urutannya bukan hal baru. Yang penting adalah setiap langkah merupakan bagian platform yang dapat dikonfigurasi, dan Anda bisa memeriksa keluarannya di setiap tahap.

Arsitektur RAGFlow

Arsitektur RAGFlow memiliki empat lapisan, dan masing-masing menyelesaikan masalah spesifik dalam pipeline RAG. Berikut gambaran visual singkatnya:

Arsitektur RAGFlow divisualisasikan

Sekarang saya jelaskan tiap lapisannya.

Ingestion dokumen

Ini adalah titik masuk. RAGFlow menerima PDF, dokumen Office seperti Word, Excel, dan PowerPoint, file Markdown, serta halaman web. Dokumen hasil pindai dan gambar juga didukung karena OCR sudah terpasang.

Anda dapat mengunggah file langsung melalui UI, menghubungkan sumber cloud, atau mendorong dokumen melalui API. Lapisan ingestion menormalisasi semuanya ke format umum sebelum melanjutkan ke tahap berikutnya.

Pemrosesan pengetahuan

Di sinilah DeepDoc berperan.

Parsing mengubah file mentah menjadi konten terstruktur dengan judul, paragraf, tabel, dan gambar. Chunking membagi konten itu menjadi unit retrieval berdasarkan templat yang Anda pilih (General, Paper, Book, Q&A, Manual, Table, atau Naive). Ekstraksi metadata menautkan konteks ke tiap chunk, seperti nomor halaman, judul bagian, dan posisi di halaman.

Chunk yang keluar dari lapisan ini mempertahankan strukturnya. Artinya, tabel tetap menjadi tabel, judul tetap bersama bagiannya, dan keterangan gambar tetap bersama gambarnya. Hasilnya tidak terasa acak seperti strategi chunking RAG tradisional.

Mesin retrieval

Mesin retrieval berjalan di atas Elasticsearch atau Infinity, tergantung mesin dokumen yang Anda konfigurasi.

Ia menjalankan tiga jenis pencarian secara paralel:

• Pencarian vektor untuk kemiripan semantik
• Pencarian kata kunci BM25 untuk kecocokan istilah eksak
• Reranking di atas hasil gabungan untuk mendorong chunk paling relevan ke urutan teratas

Lapisan ini memberikan sejumlah kecil chunk berkualitas tinggi yang dimasukkan ke prompt LLM.

Lapisan LLM

Lapisan LLM mengirimkan chunk yang diambil ke model apa pun yang Anda hubungkan - OpenAI, DeepSeek, Gemini, Claude, model lokal Ollama, atau yang lainnya yang didukung RAGFlow.

Jawaban kembali dengan sitasi. Setiap klaim pada jawaban mengarah ke chunk tertentu, dan setiap chunk mengarah ke lokasi spesifik di dokumen sumber. Inilah yang disebut RAGFlow sebagai grounded answers - pengguna bisa mengeklik sitasi dan melihat potongan persis asalnya, sehingga halusinasi mudah dideteksi.

Keempat lapisan bekerja sebagai pipeline. Ingestion memberi makan pemrosesan pengetahuan, pemrosesan pengetahuan memberi makan mesin retrieval, dan mesin retrieval memberi makan lapisan LLM.

Fitur Utama RAGFlow

Berikut fitur yang paling penting saat Anda membangun sistem RAG pada dokumen dunia nyata yang berantakan.

Parsing dokumen tingkat lanjut

Parser RAGFlow bernama DeepDoc, dan inilah alasan platform ini ada.

DeepDoc menjalankan tiga model visi pada setiap dokumen: OCR untuk ekstraksi teks, TSR untuk pengenalan struktur tabel, dan DLR untuk pengenalan tata letak dokumen. Jadi alih-alih memperlakukan PDF sebagai aliran karakter, ia membaca file layaknya manusia - melihat di mana tabel berada, di mana kolom terputus, mana teks yang merupakan judul, dan mana catatan kaki.

Struktur itu mengalir ke chunk. Tabel tetap bersama header-nya, tata letak multi-kolom dibaca dalam urutan yang benar, dan gambar mempertahankan keterangannya.

Jika Anda pernah mencoba melakukannya secara manual, Anda tahu betapa sulitnya melakukan bagian ini dengan baik pada berbagai jenis dokumen dan dalam skala besar.

Retrieval hibrida

Pencarian semantik sering meleset pada kueri yang menuntut kecocokan kata persis. Pencarian kata kunci saja meleset pada kueri yang maknanya penting namun redaksinya berbeda.

RAGFlow menjalankan keduanya sekaligus:

• Pencarian vektor menangkap kecocokan semantik - "revenue" menemukan "sales" dan "income"
• Pencarian kata kunci menangkap kecocokan eksak - kode produk atau istilah hukum tetap muncul meski model embedding tidak memahaminya
• Reranking mengambil hasil gabungan lalu menyusunnya ulang dengan model khusus, sehingga chunk teratas benar-benar paling relevan

Pembuat alur kerja

Pembuat alur kerja adalah kanvas visual tempat Anda mengonfigurasi pipeline alih-alih menulis kode.

Anda menyeret komponen ke kanvas - retrieval, rerank, LLM, eksekusi kode, panggilan HTTP, iterasi, percabangan - lalu menghubungkannya menjadi sebuah alur. RAGFlow menyertakan templat siap pakai untuk pola umum seperti Retrieve - Rerank - Answer, Deep Research, dan Data Analytics.

Bagi tim yang sebagian besar bukan engineer, inilah cara membuat prototipe yang berfungsi dalam seminggu.

Dukungan agen

Sejak v0.20, RAGFlow mendukung alur kerja agentic penuh pada kanvas yang sama dengan alur kerja reguler.

Komponen agen dapat merencanakan, merefleksi, memanggil tool, dan mendelegasikan ke sub-agen. Anda mengonfigurasi prompt dan daftar tool, dan agen memutuskan saat runtime tool mana yang dipanggil dan dalam urutan apa. Tool bisa berupa komponen bawaan, server MCP yang Anda hubungkan, atau agen lain.

Nilainya adalah penalaran atas pengetahuan yang di-retrieve. 

Agen dukungan dapat mengambil dari basis pengetahuan, memanggil API eksternal untuk memeriksa status tiket, dan memutuskan apakah perlu eskalasi. Semua itu dilakukan dalam satu alur, dengan sitasi terlampir pada bagian yang berasal dari dokumen.

Parsing Dokumen dan Ekstraksi Pengetahuan

Kualitas retrieval dimulai dari kualitas parsing. Jika bagian ini salah, tidak ada reranker atau LLM yang lebih besar yang dapat membantu.

Kebanyakan kegagalan RAG terjadi pada level dokumen, misalnya PDF penuh tabel diekstrak menjadi nilai dipisah koma atau slide deck kehilangan hierarki visualnya. Saat chunk tersebut mencapai basis data vektor, nilainya sudah hilang.

Pendekatan RAGFlow adalah memperlakukan parsing sebagai masalah kelas satu.

Tabel

Tabel adalah bagian tersulit dari parsing dokumen. Parser PDF standar membaca tabel baris demi baris dan mengubahnya menjadi aliran angka tanpa header. Anda kehilangan strukturnya.

DeepDoc menjalankan Table Structure Recognition (TSR) sebelum chunking. Ia mengidentifikasi batas tabel, baris header, kolom, dan relasi sel. Saat chunker membagi dokumen, tabel tetap utuh dengan header-nya, dan setiap baris mempertahankan konteksnya.

Gambar dan hasil pindai

DeepDoc menggunakan OCR untuk mengekstrak teks dari halaman hasil pindai, dan sejak v0.19, ia dapat menggunakan model visi-bahasa untuk memahami gambar di dalam file PDF dan DOCX.

Artinya diagram, grafik, atau foto struk belanja bisa menjadi konten yang dapat dicari.

Tata letak multi-kolom

Makalah akademik dan laporan keuangan menggunakan tata letak multi-kolom. Parser naif membacanya kiri ke kanan, baris demi baris, yang mencampur kolom dan menghasilkan konten yang tidak masuk akal.

DeepDoc menggunakan Document Layout Recognition (DLR) untuk menentukan urutan baca terlebih dahulu. Ia mengetahui kolom 1 datang sebelum kolom 2, dan bahwa sebuah header membentang di atas kedua kolom.

Metadata

Setiap chunk dilengkapi metadata, seperti nomor halaman, judul bagian, posisi di halaman, dan nama file sumbernya.

Inilah yang memungkinkan sitasi. Saat LLM mengutip suatu bagian, RAGFlow dapat menunjuk kembali ke halaman dan lokasi persis di dokumen sumber. Ini juga yang membuat penyaringan level chunk memungkinkan - Anda bisa mencari di dalam bagian atau dokumen tertentu.

Kualitas chunk

Bagian terakhir adalah chunking itu sendiri. RAGFlow menggunakan chunking berbasis templat, artinya Anda memilih templat yang sesuai dengan jenis dokumen Anda (General, Paper, Book, Q&A, Manual, Table, atau Naive).

Setiap templat menerapkan aturan berbeda untuk titik pemisahan. Templat Paper mempertahankan abstrak, metode, dan hasil sebagai unit terpisah. Templat Q&A menjaga setiap pertanyaan tetap dengan jawabannya. Templat Manual menghormati judul dan prosedur. Anda paham maksudnya.

Hasilnya adalah chunk yang masuk akal secara mandiri. Saat dimasukkan ke jendela konteks LLM, chunk tersebut cukup bermakna untuk menjawab pertanyaan.

Retrieval di RAGFlow

Setelah dokumen Anda diparse dan di-chunk, langkah retrieval akan menentukan apakah LLM melihat konteks yang tepat. Mesin retrieval RAGFlow memiliki tiga bagian yang bekerja bersama.

Retrieval vektor

Pencarian vektor menangkap kemiripan semantik. Anda membuat embedding untuk kueri dan setiap chunk dengan model yang sama, lalu mesin mengembalikan chunk yang vektornya paling dekat dengan vektor kueri.

Inilah yang memungkinkan pencarian "revenue growth" menemukan chunk tentang "sales increase" meski kedua istilah tidak muncul satu sama lain. RAGFlow memungkinkan Anda memilih model embedding - OpenAI, Cohere, Voyage, BGE, atau yang lokal - dan mengubahnya nanti tanpa membangun ulang seluruh sistem.

Pencarian hibrida

Pencarian vektor bukan yang terbaik untuk istilah eksak. Hal seperti kode produk atau rujukan hukum mungkin tidak memiliki sinyal semantik kuat, tetapi kecocokan string persis sangat penting.

RAGFlow menjalankan pencarian kata kunci BM25 bersamaan dengan pencarian vektor dan menggabungkan hasilnya. Anda mendapatkan jangkauan semantik dari embedding dan presisi pencocokan kata kunci dalam satu kueri.

Reranking

Putaran pertama retrieval memberi Anda set kandidat - biasanya 30 atau 50 chunk teratas. Itu terlalu banyak untuk jendela konteks LLM, dan bagian teratas daftar sering bising.

Reranking mengambil kandidat tersebut dan menyusunnya ulang dengan model khusus yang membaca kueri dan setiap chunk bersama-sama. Reranker mengetahui apa yang relevan terhadap kueri, bukan sekadar mirip. Lima atau sepuluh chunk teratas setelah reranking adalah yang dimasukkan ke prompt.

Pemilihan konteks

Langkah terakhir adalah memutuskan apa yang masuk ke konteks LLM. RAGFlow memungkinkan Anda menetapkan jumlah chunk, ambang kemiripan, dan skor minimal reranker.

Anda juga dapat menggunakan opsi lanjutan seperti RAPTOR (perangkuman hierarkis untuk pertanyaan multi-hop) atau long-context RAG (daftar isi level dokumen yang dihasilkan otomatis untuk memberi LLM peta materi sumber). Opsi ini tersedia untuk kasus di mana retrieval chunk datar tidak cukup.

Inti dari mesin retrieval adalah memberi LLM konteks yang tepat dan tidak lebih dari itu.

RAGFlow vs Pipeline RAG Tradisional

Pipeline RAG tradisional dibangun dari alat-alat independen. Anda memilih parser (Unstructured, LlamaParse, PyMuPDF), chunker (pemecah teks LangChain, kode kustom), model embedding, basis data vektor (Pinecone, Weaviate, Chroma, Qdrant), reranker (Cohere, BGE), klien LLM, dan UI. Lalu Anda menulis kode yang menyatukan semuanya.

Pendekatan ini memberi Anda kontrol maksimal, tetapi membutuhkan banyak upaya rekayasa.

Setiap titik integrasi adalah kode yang harus Anda rencanakan, tulis, uji, dan rawat. Saat Anda ingin menambahkan pelacakan sitasi, Anda harus membangunnya. Demikian pula, ketika suatu komponen mengubah API-nya, Anda memperbaiki pipeline-nya.

RAGFlow mengambil pendekatan sebaliknya.

Ini adalah platform terintegrasi di mana parsing, chunking, retrieval, reranking, sitasi, orkestrasi alur kerja, dan UI web sudah tersedia. Anda mengonfigurasi melalui antarmuka web alih-alih kode, dan semua bagiannya sudah terhubung.

Yang Anda korbankan adalah fleksibilitas. Jika Anda ingin mengganti algoritme chunking baru atau reranker riset, Anda bekerja dalam model plugin RAGFlow alih-alih menulis Python. Untuk sebagian besar kasus produksi, itu tidak masalah, namun untuk penggunaan eksperimental bisa terasa cukup membatasi.

Berikut ringkasan perbedaan:

Tidak ada pendekatan yang selalu lebih baik. Jika Anda punya waktu rekayasa dan butuh kontrol penuh, pipeline tradisional adalah pilihan tepat. Jika Anda ingin fokus pada basis pengetahuan, RAGFlow akan lebih cepat.

RAGFlow vs LangChain dan LlamaIndex

Jika Anda mempertimbangkan RAGFlow, kemungkinan Anda sudah mendengar tentang LangChain dan LlamaIndex. Berikut perbandingannya.

LangChain

LangChain adalah framework aplikasi untuk aplikasi LLM. Tugas utamanya adalah orkestrasi, yaitu merangkai prompt, tool, memori, dan model ke dalam alur kerja. LangChain tidak terlalu peduli bagaimana dokumen Anda diparse atau bagaimana retrieval Anda disusun. Ia berfokus pada apa yang terjadi setelah retrieval.

Jika proyek Anda berat pada agen - pemanggilan tool, penalaran multi-langkah, logika bercabang, human-in-the-loop - LangChain (dan lapisan state machine-nya, LangGraph) adalah yang paling sering dipakai tim.

LlamaIndex

LlamaIndex adalah framework data untuk LLM. Fokusnya pada ingestion data, membangun indeks atas data itu, dan melakukan kueri dengan baik. LlamaIndex memiliki 160+ konektor data, beberapa jenis indeks (vektor, kata kunci, pohon, knowledge graph), dan default yang masuk akal untuk chunking dan retrieval.

Jika proyek Anda berat pada retrieval, dengan banyak dokumen, kebutuhan pencarian mendalam, dan beragam sistem sumber, LlamaIndex adalah pilihan code-first terkuat.

RAGFlow

RAGFlow adalah platform RAG terintegrasi. Ia bukan pustaka yang Anda import dan gunakan di Python - ini adalah sistem yang Anda deploy. Parsing, chunking, retrieval, reranking, sitasi, alur kerja, agen, dan UI web sudah termasuk di dalamnya.

Jika prioritas Anda adalah menjalankan sistem RAG produksi pada dokumen berantakan tanpa menulis kode pipeline dari nol, RAGFlow adalah jalur tercepat.

Ketiga alat ini juga bisa dipadukan. Pola umum adalah LlamaIndex untuk ingestion, LangChain atau LangGraph untuk orkestrasi agen, dan RAGFlow saat Anda menginginkan tumpukan lengkap yang self-hosted alih-alih kode rakitan sendiri.

Berikut ringkasannya:

Membangun Aplikasi RAG dengan RAGFlow

Setelah RAGFlow berjalan, membangun aplikasi RAG mengikuti lima langkah. Sekali lagi, Anda tidak menulis kode pipeline, Anda hanya mengonfigurasi setiap langkah melalui UI atau API.

Ingest dokumen

Mulailah dengan mengunggah dokumen Anda. Anda dapat menambahkan file melalui UI web, menghubungkan sumber data seperti Google Drive, S3, Notion, Confluence, atau Discord, atau menambahkan file melalui API.

Contoh ingestion dokumen

RAGFlow menerima sebagian besar format umum, jadi Anda tidak perlu mengonversi apa pun di awal.

Konfigurasikan basis pengetahuan

Basis pengetahuan di RAGFlow adalah kontainer untuk dokumen, chunk, dan pengaturan Anda. Anda memilih templat chunk yang sesuai dengan jenis dokumen (General untuk konten campuran, Paper untuk riset, Manual untuk dokumen teknis, Q&A untuk tiket dukungan, dan seterusnya), memilih model embedding, dan memilih parser.

Konfigurasi basis pengetahuan

Ingat bahwa langkah ini penting, karena pilihan templat yang tepat akan mengurangi banyak kerepotan di kemudian hari.

Pilih strategi retrieval

Selanjutnya, tentukan cara kerja retrieval. Anda menetapkan jumlah chunk teratas yang dikembalikan, ambang kemiripan, dan apakah akan menggunakan pencarian hibrida atau hanya pencarian vektor. Anda juga bisa menyalakan reranking dan memilih model reranker.

Untuk kasus lanjutan, RAGFlow mendukung RAPTOR untuk perangkuman hierarkis dan knowledge graph untuk retrieval berbasis entitas. Anda bisa mengaktifkannya di dalam konfigurasi basis pengetahuan.

Hubungkan LLM

RAGFlow tidak menyertakan LLM. Anda membawa milik Anda sendiri - OpenAI, DeepSeek, Gemini, Claude, model lokal melalui Ollama, atau apa pun yang didukung RAGFlow.

Opsi model

Anda menambahkan kunci API di pengaturan, memilih model, dan menetapkan system prompt. 

Uji jawaban

Langkah terakhir adalah pengujian. RAGFlow memiliki antarmuka chat tempat Anda dapat menanyakan basis pengetahuan dan melihat jawaban dengan sitasi terlampir.

Klik sitasi apa pun, dan Anda akan menuju ke chunk persisnya dengan posisinya di dokumen sumber yang ditandai.

Kebanyakan tim mengulang langkah ini beberapa kali sebelum jawaban bisa digunakan. Itu normal untuk sistem RAG mana pun, tetapi dengan RAGFlow Anda mengubah pengaturan di UI alih-alih menulis ulang kode Python.

Contoh konfigurasi chat

RAGFlow di Produksi

Anda akan melihat RAGFlow digunakan di produksi untuk serangkaian use case tertentu, terutama yang paling menuntut kualitas dokumen dan pelacakan sitasi.

Basis pengetahuan perusahaan

Perusahaan besar memiliki ribuan dokumen tersebar di drive bersama, Confluence, SharePoint, dan PDF pada lampiran email. Karyawan biasanya tidak bisa menemukan yang mereka butuhkan, dan bertanya pada LLM tanpa RAG memunculkan halusinasi.

RAGFlow bekerja baik di sini.

PDF lama, dokumen kebijakan hasil pindai, lembar Excel dengan pivot table, deck PowerPoint bertahun-tahun lalu - semuanya bisa diparse. Dan dengan sitasi, tim legal dan kepatuhan bisa mempercayai jawaban, serta UI web memungkinkan non-engineer memelihara basis pengetahuan.

Asisten dukungan pelanggan

Tim dukungan memiliki riwayat tiket bertahun-tahun, FAQ, manual produk, dan runbook internal. Asisten dukungan harus mencari semuanya, menemukan bagian yang tepat, dan tahu kapan harus eskalasi.

Templat chunk Q&A RAGFlow dibuat untuk ini. Anda memberinya riwayat tiket dan ia memperlakukan setiap pasangan tanya-jawab sebagai unit retrieval. Jika Anda menambahkan lapisan agen di atasnya, sambungkan API untuk pencarian pesanan, dan Anda memiliki asisten yang menangani pertanyaan rutin serta menyerahkan yang rumit dengan konteks lengkap.

Pencarian dokumentasi internal

Tim engineering memiliki runbook, dokumen arsitektur, postmortem insiden, dan referensi API yang tersebar di Notion, Confluence, dan GitHub. Grep berguna untuk kata kunci, tetapi tidak membantu untuk "bagaimana kami menangani kejadian terakhir saat peringatan ini muncul?"

RAGFlow memberi Anda pencarian semantik atas seluruh korpus dengan sitasi kembali ke sumber. Ini berarti engineer bisa mendapatkan potongan teks dan tautan ke halaman asli dalam satu klik.

Asisten riset

Tim riset bekerja dengan makalah, paten, laporan, dan eksperimen internal. Templat Deep Research di RAGFlow dirancang untuk ini, karena memiliki retrieval multi-giliran dengan penalaran chain-of-thought, di mana agen mengurai pertanyaan, mencari potongan jawabannya, dan menyusunnya.

Untuk riset keuangan, hukum, dan farmasi, kemampuan menelusuri setiap klaim ke sumbernya adalah yang membuat asisten tersebut layak digunakan.

Benang merah di seluruh use case ini adalah dokumen yang menjadi bagian tersulit. Jika materi sumber Anda bersih dan sederhana, sebagian besar alat RAG berfungsi. Jika berantakan dan terstruktur, lapisan parsing RAGFlow kemungkinan akan membawa Anda lebih jauh daripada menulis pipeline dari nol.

Mendeploy RAGFlow

RAGFlow memberi Anda tiga jalur deployment. Berikut penjelasannya.

Deployment Docker

Docker Compose adalah jalur utama. Anda mengklon repo, cd ke folder docker, dan jalankan docker compose up -d. Itu akan menyalakan server RAGFlow bersama Elasticsearch, MinIO, MySQL, dan Redis.

Spesifikasi minimum adalah 4 inti CPU, RAM 16 GB, dan disk 50 GB. Dalam praktiknya Anda akan menginginkan RAM lebih besar jika menjalankan koleksi dokumen besar, karena Elasticsearch dan Infinity membutuhkan banyak memori.

Citra Docker menargetkan x86, jadi perlu diingat. Jika Anda menggunakan Apple Silicon atau mesin ARM64 lain, lapisan translasi dapat membuatnya berjalan, tetapi untuk kinerja lebih baik Anda sebaiknya membangun citra sendiri menggunakan panduan ARM64 di dokumentasi RAGFlow.

Pengembangan lokal

Jika Anda ingin memodifikasi kode sumber RAGFlow, Anda dapat menjalankan backend dan frontend dari sumber. Anda menggunakan uv untuk dependensi Python, jalankan docker compose -f docker/docker-compose-base.yml up -d untuk menyalakan layanan pendukung saja (MinIO, Elasticsearch, MySQL, Redis), lalu mulai backend dengan skrip shell dan frontend dengan npm run dev.

Jalur ini hanya layak jika Anda berkontribusi ke proyek atau debugging. Bagi sebagian besar pengguna, jalur Docker Compose lebih cepat.

Deployment cloud

InfiniFlow menjalankan versi hosted di cloud.ragflow.io. Ada paket gratis dengan 5 app dan 500 kredit per bulan, serta paket berbayar $29, $129, dan harga enterprise.

Versi cloud cocok untuk prototipe dan tim kecil. Untuk penggunaan produksi serius dengan data sensitif, kebanyakan tim melakukan self-host pada infrastruktur mereka sendiri, baik pada satu VM untuk deployment kecil atau di Kubernetes menggunakan Helm chart untuk yang lebih besar.

Pertimbangan skala

Deployment default RAGFlow menjalankan semuanya pada satu mesin. Itu baik-baik saja sampai titik tertentu, tetapi setelah itu Anda akan menemui batas pada jumlah dokumen, beban kueri, atau ukuran tim.

Komponen yang diskalakan secara independen adalah mesin dokumen (Elasticsearch atau Infinity), penyimpanan objek (MinIO), dan aplikasi RAGFlow itu sendiri. Untuk deployment besar, Anda memisahkan layanan tersebut ke beberapa mesin, menggunakan Elasticsearch terkelola atau penyimpanan objek kompatibel S3, dan menjalankan beberapa instance aplikasi RAGFlow di belakang load balancer.

Akselerasi GPU untuk DeepDoc adalah hal lain yang dapat dieksplorasi. Seperti Anda tahu, parsing secara default berat di CPU, tetapi Anda dapat mengaktifkan mode GPU di konfigurasi, yang memberi perbedaan besar pada proses ingestion dokumen berskala besar.

Sisanya adalah pekerjaan infrastruktur standar, dan RAGFlow tidak menghalangi itu semua.

Keunggulan dan Keterbatasan RAGFlow

Setiap alat punya trade-off, dan RAGFlow tidak berbeda. Berikut yang perlu Anda ketahui sebelum menggunakannya.

Keunggulan

• Ini adalah platform terintegrasi: Anda tidak perlu memilih parser, basis data vektor, reranker, chunker, dan framework UI, lalu menulis kodenya. RAGFlow menyertakan semuanya.
• Pemrosesan dokumen adalah bagian terkuat: DeepDoc menangani PDF, file hasil pindai, tabel, dan tata letak kompleks lebih baik daripada kebanyakan alternatif. Jika dokumen Anda berantakan, ini seringkali sudah cukup menjadi alasan memilih RAGFlow.
• Berorientasi produksi sejak awal: Sitasi yang ter-grounded, visualisasi chunk, alur kerja agen, dukungan MCP, dan UI manajemen yang nyata sudah terpasang. 
• Open-source di bawah Apache 2.0: Anda dapat self-host, memodifikasi kode, dan menjalankannya di infrastruktur Anda sendiri. Repo GitHub memiliki 80k+ bintang dan pengembangan aktif, jadi proyek ini tidak akan hilang dalam waktu dekat.

Keterbatasan

• Deployment tidak semudah kelihatannya di awal: Docker Compose membantu, tetapi Anda tetap menjalankan Elasticsearch atau Infinity, MinIO, MySQL, dan Redis berdampingan dengan aplikasinya. Akan ada masalah pada suatu waktu, dan Anda perlu cukup paham Docker untuk memperbaikinya.
• Kebutuhan infrastruktur: Minimumnya 16 GB RAM dan 4 inti CPU, tetapi itu untuk beban kecil. Deployment nyata membutuhkan 32 GB atau lebih, terutama jika Anda menggunakan Infinity atau menjalankan job ingestion besar. Menjalankan RAGFlow di VPS $5 tidak akan berhasil.
• Ada kurva pembelajaran: Pembuat alur kerja itu kuat, tetapi komponennya banyak, dan mencari templat chunk serta pengaturan retrieval yang tepat memakan waktu. Anda akan menghabiskan beberapa hari hingga benar-benar produktif.

Tidak ada yang menjadi penghalang jika RAGFlow sesuai dengan use case Anda. Anggap saja itu sebagai biaya untuk mendapatkan platform, bukan pustaka.

Siapa yang Sebaiknya Menggunakan RAGFlow?

RAGFlow tidak ideal untuk setiap proyek. Berikut siapa yang cocok menggunakannya dan siapa yang lebih baik memilih sesuatu yang lebih ringan.

Paling cocok

Engineer AI yang membangun sistem RAG produksi. Jika tugas Anda membuat aplikasi RAG yang berfungsi dan bukan menulis pustaka chunking lain, RAGFlow menghilangkan sebagian besar pekerjaan plumbing.

Tim AI perusahaan. Tim legal, kepatuhan, keuangan, dan dukungan membutuhkan sitasi dan keterlacakan. UI yang dapat digunakan non-engineer juga menjadi nilai tambah. 

Developer yang bekerja dengan dokumen berantakan. PDF penuh tabel, file hasil pindai, tata letak multi-kolom, dan format campuran adalah area di mana DeepDoc lebih unggul dari kompetitor. Jika materi sumber Anda bukan teks bersih, kualitas parsing RAGFlow sulit ditandingi.

Organisasi dengan koleksi dokumen besar. Setelah melewati beberapa ribu dokumen, Anda butuh sistem yang bisa melakukan ingestion, pengindeksan, dan pencarian berskala. RAGFlow adalah alat yang tepat untuk pekerjaan ini.

Kurang ideal

Prototipe chatbot sederhana. Jika Anda hanya perlu menjawab pertanyaan dari beberapa file Markdown, RAGFlow terlalu berlebihan. Skrip LlamaIndex atau pipeline LangChain sederhana lebih cepat.

Proyek sangat kecil. Untuk tanya jawab personal atas beberapa PDF, biaya infrastruktur terlalu berat. Anda akan lebih banyak menghabiskan waktu pada perintah Docker daripada proyek sebenarnya.

Tim yang menginginkan zero setup. Jika Anda ingin mendaftar dan mendapatkan RAG yang berfungsi dalam lima menit, layanan hosted atau pustaka ringan lebih cocok. RAGFlow memiliki versi cloud, tetapi jalur self-hosted (yang paling bernilai) membutuhkan beberapa pekerjaan penyiapan.

Aturan praktisnya sederhana. Jika kualitas retrieval pada dokumen berantakan adalah bagian tersulit dari proyek Anda, RAGFlow layak untuk biaya penyiapannya. Jika tidak, gunakan sesuatu yang lebih ringan.

Kesimpulan

RAGFlow adalah platform full-stack untuk membangun aplikasi RAG produksi pada dokumen dunia nyata.

Kekuatan terbesarnya adalah pemrosesan dokumen, retrieval, reranking, dan generasi berada dalam satu alur, bukan digabung dari alat terpisah. Anda mendapatkan parsing DeepDoc, retrieval hibrida, sitasi yang ter-grounded, dan alur kerja agen di balik satu UI dan API.

Jika dokumen Anda berantakan dan kualitas retrieval penting, RAGFlow layak untuk biaya penyiapannya.

Mulailah dengan paket cloud gratis atau deploy Docker lokal, unggah beberapa dokumen terburuk Anda, dan lihat bagaimana jawabannya kembali. Itu cara tercepat untuk mengetahui apakah cocok dengan use case Anda.

Arsitektur RAG sederhana secara desain, tetapi bukan berarti tidak dapat bekerja untuk use case kompleks. Baca posting blog Teknik RAG Lanjutan kami untuk mempelajari dense retrieval, reranking, dan penalaran multi-langkah.