Keuntungan:
- Merancang komponen dan aliran data asisten RAG perusahaan ujung ke ujung
- Menggabungkan data multi-sumber (wiki, tiket, PDF, database) menjadi satu asisten
- Buat keputusan arsitektural untuk skalabilitas, caching, dan latensi
Pada unit sebelumnya, kita telah mempelajari bagian-bagiannya satu per satu: embedding, database vektor, chunking, retrieval. Sekarang mari kita gabungkan ini dan membangun arsitektur asisten end-to-end yang berkomunikasi dengan data perusahaan Anda. Tujuannya adalah agar karyawan bertanya, “Apa kebijakan cuti kita?” Sebuah sistem di mana orang dapat mengajukan pertanyaan, jawabannya didasarkan pada dokumen internal nyata, kutipan, dan menggabungkan berbagai sumber data. Unit ini memproses seluruh arsitektur, aliran data, dan keputusan tingkat produksi.
Komponen Ujung-ke-Ujung
Asisten RAG perusahaan terdiri dari dua jalur terpisah. Jalur pengindeksan (offline) menyiapkan data; Baris kueri (online) menjawab pertanyaan tersebut.
Komponen garis pengindeksan:
- Konektor: Konektor yang mengambil data dari sumber — wiki, sistem tiket, penyimpanan file, database, email.
- Normalisasi: Mengonversi berbagai format (PDF, HTML, DOCX) menjadi teks bersih; pembersihan header/footer.
- Pemotongan + metadata: Pemotongan dan penandaan (sumber, tanggal, otoritas).
- Menyematkan + memuat: Menulis vektor dan metadata ke dalam database vektor.
Komponen alur kueri:
- Pemrosesan awal kueri: Penulisan ulang, desentralisasi.
- Pengambilan: Penelusuran hibrid + filter metadata + pemeringkatan ulang.
- Pembuatan cepat: Menempatkan konteks + pertanyaan + instruksi ke dalam template.
- Generasi: Jawaban yang membumi (kontekstual) dari model + sumber.
- Pasca-pemrosesan: Pemformatan kutipan, pemeriksaan keamanan, pencatatan.
Tip: Pisahkan secara fisik baris pengindeksan dari baris kueri. Pengindeksan lambat dan berkala (berjalan dalam batch dalam semalam); Jalur penyelidikan harus ringan dan segera. Mencampur dua baris memaksa pemrosesan yang berat sementara pengguna menunggu.
Memvisualisasikan Aliran Data
[INDEXING - offline]Sumber Daya → Normalisasi → Potongan+Metadata → Sematkan → DB Vektor (wiki, tiket, PDF, DB)[QUERY - online]Pertanyaan pengguna → Pra-pemrosesan → Pengambilan (hibrida+filter+peringkat ulang) → Prompt (konteks+pertanyaan+instruksi) → Model → Jawaban+Sumber → Pengguna
Menggabungkan Data Multi-Sumber
Di perusahaan nyata, jawabannya tidak berhenti di satu tempat. “Bagaimana cara melakukan pengembalian dana kepada pelanggan?” Jawaban atas pertanyaan tersebut dapat ditemukan di artikel bantuan (prosedur), di riwayat tiket (contoh nyata), dan di PDF polis (aturan). Asisten harus mencari semuanya dalam satu kelompok.
Poin penting: saat menggabungkan sumber daya ke dalam satu penyimpanan vektor, setiap pecahan harus membawa metadata `source_tour`. Jadi Anda bisa mencari semuanya dan memfilternya jika perlu, seperti "hanya bawa kebijakan resmi". Selain itu, berbagai sumber memiliki tingkat keandalan yang berbeda: kebijakan resmi > artikel bantuan > catatan tiket karyawan. Anda dapat menentukan prioritas ini dalam pemeringkatan ulang atau prompt.
Sumber
Jenis konten
kepercayaan
Frekuensi pembaruan
PDF Kebijakan
aturan resmi
tinggi
bulanan
Artikel bantuan
Prosedur
sedang-tinggi
mingguan
Sejarah tiket
sampel nyata
sedang
Terus menerus
wiki
Catatan campuran/saat ini
Variabel
Terus menerus
Skalabilitas, Cache, dan Latensi
Ada tiga masalah yang menonjol dalam produksi. Latensi: Pengalaman memburuk saat pengguna menunggu lebih dari 2 detik. Solusi: tampilkan jawabannya dalam bentuk streaming — jawabannya dituangkan ke layar saat model menulis. Cache: Untuk pertanyaan umum dan konteks berulang, cache meningkatkan kecepatan dan mengurangi biaya. Skala: Seiring bertambahnya jumlah pengguna, diperlukan kemampuan untuk menskalakan pengambilan dan memodelkan panggilan secara horizontal.
Aturan praktis dari sisi biaya: langkah yang paling mahal biasanya adalah jumlah token yang masuk ke model yang lebih besar. Oleh karena itu, mengurangi konteks menjadi 4 bagian yang baik dengan memberi peringkat ulang akan meningkatkan kualitas dan biaya. Desain yang umum adalah menggunakan model yang lebih kecil/cepat untuk klasifikasi atau perutean sederhana, dan model yang lebih kuat untuk jawaban akhir (misalnya claude-opus-4-8).
Perhatian: Jangan mengatur pengindeksan sebagai "lakukan sekali, lupakan saja". Dokumen diubah, dihapus, ditambahkan. Tetapkan strategi pengindeksan ulang: deteksi dokumen yang diubah dan proses ulang dokumen tersebut saja. Indeks basi menghasilkan jawaban yang tampak terkini tetapi salah.
Arsitektur Lemah / Arsitektur Kuat
Lemah (skrip tunggal, semuanya tercampur):
Ketika pengguna bertanya: membaca dokumen pada saat itu, merobeknya, menyematkannya, mencarinya, menjawabnya.# Masalah: semua pengindeksan diulangi untuk setiap pertanyaan; penundaan beberapa detik, # tidak ada pemisahan sumber, tidak ada filter, tidak ada penyegaran.
Kuat (pipa terpisah + metadata + cache + streaming):
Pengindeksan: batch berjalan pada malam hari, menyegarkan dokumen yang diubah. Kueri: garis ringan — pra-pemrosesan → pengambilan hibrid+filter → pemeringkatan ulang → prompt → model (streaming) → kutipan → log. Pertanyaan yang sering diajukan dan sumber di-cache.
Tiga Kasus Mini
Kasus 1 — Jalur bingung, penundaan berat. Sebuah startup menulis skrip yang memproses ulang PDF dengan setiap pertanyaan; Setiap jawaban memakan waktu rata-rata 11 detik. Ketika garis pengindeksan dipisahkan dan data sebelumnya ditransfer ke penyimpanan vektor, waktu kueri berkurang menjadi 1,3 detik dan dengan streaming, "kata pertama" muncul dalam 400 ms.
Kasus 2 — Terlalu banyak sumber daya, prioritas salah. Seorang asisten dukungan memberikan bobot yang sama pada PDF kebijakan dan catatan tiket lama; Model tersebut terkadang menampilkan penilaian yang salah dari seorang karyawan dari dua tahun lalu sebagai aturan resmi. Ketika metadata source_tour dan instruksi "pertimbangkan kebijakan resmi jika terjadi konflik" ditambahkan ke perintah, kesalahan prioritas palsu berkurang sebesar 89%.
Kasus 3 — Indeks basi. Seorang asisten HR bekerja dengan indeks yang tidak diperbarui selama 3 bulan; Kebijakan cuti telah berubah, namun asistennya mengatakan hal yang sama. Ketika penyegaran harian dipasang, yang mendeteksi file yang diubah, tingkat respons saat ini meningkat dari 70% menjadi 99%.
Kesalahan umum
- Mencampur pengindeksan dan baris kueri: Pemrosesan berat dilakukan saat pengguna menunggu; penundaan meledak.
- Tidak memasukkan tipe sumber ke dalam metadata: Tidak ada prioritas dan pemfilteran; Sumber yang tidak tepercaya tampaknya resmi.
- Tidak menetapkan strategi penyegaran: Indeks menjadi basi; Jawaban salah yang muncul saat ini dihasilkan.
- Lewati streaming: Pengguna melihat layar kosong; Keterlambatan yang dirasakan menjadi tinggi.
- Menggunakan model terbesar pada setiap langkah: Biaya meningkat secara tidak perlu; Serahkan kemudi pada model yang lebih kecil.
Singkatnya
- Asisten RAG perusahaan terdiri dari dua jalur terpisah: pengindeksan offline dan kueri online; memisahkan mereka secara fisik.
- Pengindeksan = konektor + normalisasi + potongan/metadata + semat/unggah; query = pra-proses + pengambilan + prompt + menghasilkan + pasca-proses.
- Data multi-sumber digabungkan ke dalam satu repositori, tetapi metadata tipe_sumber dan prioritas kepercayaan tetap dipertahankan.
- Streaming dan cache untuk latensi, pembatasan konteks, dan pemilihan model untuk biaya sangatlah penting.
- Tanpa pengindeksan ulang, indeks menjadi basi; Proses ulang perubahan dokumen secara teratur.
Tugas aplikasi
Gambarlah diagram arsitektur asisten untuk tim Anda sendiri. (1) Identifikasi setidaknya tiga sumber data nyata dan tuliskan kebutuhan konektor, frekuensi pembaruan, dan tingkat kepercayaan untuk masing-masing sumber. (2) Gambarkan garis pengindeksan dan kueri secara terpisah dengan diagram panah kotak. (3) “Di mana saya dapat mengurangi latensi dan biaya pada asisten ini?” Tuliskan setidaknya dua keputusan konkrit atas pertanyaan tersebut. (4) Jelaskan strategi penyegaran Anda dalam satu kalimat: sumber daya mana yang akan diindeks ulang dan seberapa sering?
daftar periksa
- [] Saya dapat menggambar garis pengindeksan dan kueri secara terpisah dan dengan komponen yang benar.
- [] Saya dapat menggabungkan data multi-sumber dengan source_type dan prioritas kepercayaan.
- [ ] Saya dapat membuat keputusan streaming/cache untuk latensi dan pemilihan model untuk biaya.
- [ ] Saya tahu mengapa strategi pengindeksan ulang itu penting.
- [ ] Saya ingat bahwa langkah termahal dalam arsitektur saya biasanya adalah token yang digunakan untuk model yang lebih besar.