Pasukan yang memindahkan Retrieval-Augmented Generation (RAG) daripada demo kepada perkhidmatan pengeluaran (production) akan berhadapan dengan beberapa keputusan yang membezakan pembantu yang berguna daripada yang bising. Lima pilihan reka bentuk—chunking, model embedding, stor vektor, carian hibrid, dan penilaian—mengawal ketepatan (precision), ingatan (recall), dan kependaman (latency) yang dialami oleh pengguna sebenar.

Mengapa peralihan daripada prototaip kepada pengeluaran itu penting

Kebanyakan tutorial menjalankan saluran paip (pipeline) RAG dalam beberapa baris kod sahaja, kemudian terhenti sebelum mencapai ketegasan kejuruteraan yang diperlukan untuk trafik langsung.

1. Strategi chunking – pintu gerbang kualiti pertama

Saiz chunk adalah yang paling penting. Chunk yang besar menenggelamkan isyarat dengan teks yang tidak berkaitan; chunk yang terlalu kecil pula menghilangkan konteks sekeliling yang diperlukan oleh model untuk menjana jawapan yang koheren. Pembahagian saiz tetap (fixed-size splitting) mengabaikan struktur semula jadi bahan sumber.

Peraturan praktikal (rule-of-thumb)

  • Bahagikan pada sempadan logik: pengepala dalam dokumen, pemutusan perenggan dalam artikel, definisi fungsi dalam kod.
  • Pastikan chunk cukup kecil untuk pengambilan (retrieval) yang tepat tetapi kekalkan bahagian induk (parent section) yang lebih besar untuk langkah penjanaan LLM. Corak “parent-child” ini membolehkan perolehan (retriever) memaparkan petikan yang tepat sementara penjana (generator) melihat konteks yang mencukupi untuk kekal faktual.

2. Model embedding – bagaimana keserupaan dinilai

Model embedding menukarkan teks kepada vektor yang dibandingkan oleh enjin carian keserupaan. Model tujuan umum yang kuat seperti text-embedding-3-large daripada OpenAI memberikan asas yang kukuh untuk kebanyakan domain. Jika korpus berada dalam bidang yang sangat khusus—pendapat undang-undang, rekod perubatan, spesifikasi teknikal—uji model khusus domain, tetapi hanya selepas anda mengukur peningkatan ketara pada data anda sendiri.

Bila perlu bertukar

  • Bertukar hanya jika anda melihat peningkatan boleh ukur dalam skor relevansi yang penting untuk aplikasi anda (contohnya, ketepatan konteks yang lebih tinggi).

3. Pangkalan data vektor – menskalakan storan

Pilih stor vektor yang sesuai dengan infrastruktur sedia ada anda dan jumlah vektor yang dijangkakan.

  • pgvector berjalan di dalam PostgreSQL dan mengendalikan sehingga kira-kira satu juta vektor dengan selesa. Ia ideal untuk pasukan yang sudah mengendalikan pangkalan data hubungan dan memerlukan penyelesaian penyelenggaraan rendah.
  • Qdrant menyerlah dalam julat 1 Juta–100 Juta, memberikan daya pemprosesan (throughput) yang lebih tinggi dan kependaman yang lebih rendah untuk korpus yang lebih besar.
  • Pinecone menyediakan perkhidmatan awan yang diurus sepenuhnya, menghapuskan beban operasi hos kendiri (self-hosting).

4. Carian hibrid dan reranking – mengimbangi makna dan ketepatan

Carian vektor tulen cemerlang dalam keserupaan semantik tetapi boleh terlepas padanan kata kunci tepat yang diharapkan oleh pengguna. Carian hibrid meletakkan indeks kata kunci BM25 tradisional di atas indeks vektor, kemudian menggabungkan kedua-dua senarai keputusan tersebut. Reciprocal Rank Fusion (RRF) memberikan skor kepada setiap calon berdasarkan kedudukannya dalam kedua-dua senarai dan menggabungkannya, sekali gus meningkatkan item yang muncul tinggi dalam mana-mana senarai.

Reranking menambah penapis ketepatan terakhir. Selepas pengambilan hibrid, masukkan calon top-N (biasanya 50) ke dalam cross-encoder—sebuah model yang memberikan skor kepada pasangan pertanyaan-dokumen secara bersama. Skor cross-encoder menggantikan nombor keserupaan asal, membolehkan anda memilih chunk yang paling relevan sebelum menyerahkannya kepada LLM. Langkah tambahan ini sering menghasilkan lonjakan ketara dalam kualiti jawapan, terutamanya untuk korpus yang panjang atau bising.

5. Penilaian dan abstention – mengukur apa yang penting

Anda tidak boleh menambah baik sistem yang tidak anda ukur. Rangka kerja RAGAS mencadangkan empat metrik yang secara kolektif merangkumi kesihatan saluran paip RAG:

  • Context Precision – nisbah chunk yang diambil yang sebenarnya mengandungi jawapan.
  • Context Recall – bahagian daripada semua chunk relevan yang telah diambil.
  • Faithfulness – sejauh mana jawapan yang dijana kekal dalam konteks yang diambil, mengelakkan halusinasi.
  • Answer Relevance – sejauh mana jawapan akhir memenuhi pertanyaan asal.

Jejaki metrik ini pada set ujian berterusan yang mencerminkan trafik pengeluaran.

Langkah keselamatan terakhir yang sering diabaikan ialah abstention. Daripada memaksa model untuk menjawab dengan keyakinan rendah, tetapkan ambang (threshold) pada skor faithfulness atau relevansi yang mencetuskan respons “Saya tidak tahu”. Pengguna lebih suka pengakuan ketidakpastian yang jelas berbanding jawapan yang yakin tetapi salah, dan langkah sandaran (fallback) ini mengurangkan kos sokongan hiliran.

Anggap setiap satu daripada lima bidang ini sebagai titik keputusan dan bukannya konfigurasi "set-and-forget", dan anda boleh memindahkan RAG daripada demo yang gah kepada perkhidmatan pengeluaran yang boleh dipercayai. Hasilnya: sistem yang menjawab dengan cepat, kekal pada topik, dan tahu bila perlu berdiam diri.