Catatan Teknik Naly: Draf Artikel RAG Berbasis Sumber untuk Publikasi yang Bertahan dan Dapat Diaudit

TL;DRRetrieval-augmented generation (RAG) menjadikan pipeline artikel Naly menjadi sistem publikasi berbasis sumber, bukan komposisi dari memori model. Setiap permintaan draf pertama-tama mengumpulkan bukti web dan arXiv, menormalkan dan mempertahankan URL sumber, lalu meminta model menghasilkan draf yang berfokus pada jawaban dan artikel HTML final. Ini menggeser risiko dari “dapatkah model berhalusinasi?” menjadi “apakah lapisan retrieval lengkap dan dapat dilacak,” memberi editor artefak yang stabil, job yang bisa direplay, dan klaim publik yang dapat dipertanggungjawabkan.

Abstrak

RAG di Naly sebaiknya dirancang seputar persistensi sumber dan kontrak yang deterministik. Pada 27 Juni 2026, reliabilitas praktis datang bukan dari model yang lebih besar, melainkan apakah artefak retrieval dapat di-query, diversi, dan divalidasi sebelum publikasi. Catatan ini mengusulkan desain dua bidang: bidang bukti untuk retrieval/storage dan bidang generasi untuk drafting, lalu menjelaskan bagaimana arsitektur ini langsung memperbaiki kepercayaan editorial dan penanganan insiden.

Posisinya di Naly

Naly menjalankan ini sebagai subsistem konten produksi di dalam stack Next.js 16.0.7 App Router ( next + react), di mana publikasi artikel adalah bagian dari jalur kode runtime, bukan langkah penulisan terpisah secara offline. Jalur article-job adalah titik di mana semua batasan harus ditegakkan: sebuah job tidak "ditulis" sampai catatan sumber ada, struktur ringkasan tervalidasi, dan HTML dimaterialisasi.

Penyesuaian stack ini disengaja:

next@16.0.7 + Komponen React Server Components menjadi host rendering yang dipicu job di ruang server, menyelaraskan kontrak output sisi server untuk artikel.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 mendefinisikan tabel job dan sumber yang bertipe serta persisten agar setiap klaim dapat dilacak.
ai@6.0.0-beta.105 memberikan generasi dengan kontrol output yang peka skema.
marked@17.0.1 mengonversi ringkasan Markdown yang dihasilkan menjadi HTML yang dirender untuk publikasi.
@vercel/blob@2.0.0 menyimpan aset yang dihasilkan sebagai URL yang tahan lama untuk penggunaan ulang.
Alat dari Anthropic dapat ditambahkan sebagai penyedia model alternatif di dalam envelope kontrak yang sama, tetapi bukan sebagai jalan keluar dari batasan terstruktur.

Ini menggantikan model “generate then proofread” dengan alur penulisan berbasis bukti: retrieval, validasi, generasi, rendering, dan publish harus semuanya lolos sebelum artikel terlihat.

Mekanisme teknis

Desain Naly yang tangguh memiliki lima tahap yang dibatasi:

Rencana bukti dan orkestrasi query

Definisikan spesifikasi job dengan topik, jendela tanggal, dan kebijakan bukti.
Jalankan pencarian web dan pencarian arXiv untuk sumber primer.
Lakukan deduplikasi berdasarkan URL kanonik dan normalisasi protokol, host, dan query string.

Lapisan persistensi sumber

Simpan metadata per-URL (urlURL kanonik, status ambil, stempel waktu ambil, judul, kutipan, jenis sumber).
Simpan potongan yang dihadapi model secara terpisah dari payload mentah sehingga re-run menjadi deterministik meski halaman upstream bergeser.
Tambahkan checksum per-sumber untuk mendeteksi drift.

Pembentukan konteks dan batasan

Bangun konteks retrieval yang diurutkan berdasarkan relevansi dan recency.
Wajibkan ID sumber yang eksplisit di dalam kontrak prompt.
Paksa bentuk output answer-first (intro claim, evidence bullets, risk caveats, uncertainty), disertai referensi sumber yang berurutan.

Generasi terstruktur dengan skema ketat

Gunakan output terstruktur agar respons yang salah format atau melanggar skema gagal cepat dan diulang dengan konteks yang lebih ketat.
Pertahankan generasi di konteks server dan tolak draft yang mengklaim fakta yang tidak didukung tanpa ID sumber yang dipetakan.

Render, terbitkan, dan verifikasi

Konversi markdown yang tervalidasi menjadi HTML dan simpan markdown + HTML secara persisten.
Cache output final hanya setelah validasi berhasil.
Emisikan field analitik dan audit: jumlah sumber, klaim yang ditolak, jumlah retry, dan latensi generasi.

Perubahan desain paling penting adalah pemisahan tanggung jawab: kualitas retrieval dan kualitas generasi adalah domain kegagalan yang berbeda dengan metrik yang berbeda. Next.js Server Components cocok untuk pemisahan ini karena rendering bisa tetap deterministik sementara retrieval dan generasi berjalan pada tugas async terkendali.

Apa yang dikatakan literatur

Literatur RAG terbaru mendukung pola arsitektur ini. Survei RAG tahun 2024 menjelaskan bagaimana sistem berbasis retrieval-retrieval mengurangi drift fakta dengan mengondisikan generasi pada bukti eksternal, tetapi mencatat trade-off pada kompleksitas pipeline dan koordinasi modular [Gupta et al., 2024]. Survei lanjutan tahun 2025 menambahkan bahwa ketangguhan kini bergantung pada retrieval adaptif, kontrol decoding, dan evaluasi end-to-end, bukan hanya kualitas generasi [Sharma, 2025].

Untuk kontrol kualitas produksi, survei evaluasi tahun 2025 secara eksplisit memisahkan penilaian menjadi metrik retriever/generator internal dan metrik sistem eksternal; dekomposisi ini sangat berguna untuk pipeline artikel karena “artikel buruk” bisa berarti pemilihan sumber yang salah meski kualitas bahasanya tinggi [Gan et al., 2025]. Pekerjaan yang berfokus pada groundedness juga bergerak menuju lapisan deteksi yang mengklasifikasikan dukungan klaim menggunakan konteks yang diambil dan pemeriksaan ala NLI, memperkuat nilai praktis validasi pasca-generasi [Gerner et al., 2025].

Singkatnya, para paper bertemu pada satu tesis: RAG bukan sekadar cara menyuntikkan konteks, melainkan kontrak rekayasa antara retrieval dan generasi. Karena itu Naly perlu mengoptimalkan kontrak, bukan hanya prompt.

Trade-off desain

Kebaruan vs determinisme: TTL yang lebih ketat mengurangi keterbaruan data lama tetapi meningkatkan biaya re-fetch. Menyimpan snapshot memungkinkan rendering yang tetap deterministik sambil tetap memvalidasi jendela freshness.
Recall vs precision dalam retrieval: retrieval yang lebih luas dapat meningkatkan cakupan tetapi menambah noise; filter relevansi tahap kedua melindungi kualitas klaim.
Ketatnya skema vs kelancaran prosa: skema output yang ketat meningkatkan reliabilitas mesin tetapi dapat mengurangi kebebasan gaya. Pola answer-first schema tetap menjaga keterbacaan sambil mempertahankan guardrail.
Kecepatan rendering statis vs keterauditan: HTML yang diprerender meningkatkan performa pengiriman dan mengurangi komputasi berulang, tetapi hanya jika artefak sumber yang dipakai adalah referensi yang immutable.
Kompleksitas vs biaya operasi: setiap langkah validasi tambahan (cek sumber, cek skema, persistensi artefak) menambah latensi. Panduan produksi selanjutnya terkait caching, batas rute, dan verifikasi saat build penting agar sistem ini tetap operasional.

Mode kegagalan

Source drift: URL mengembalikan 404/soft-change setelah job dibuat. Mitigasi: kunci kanonik + hash snapshot + rantai sumber cadangan.
Retrieval overreach: recall tinggi dengan precision rendah menimbulkan sintesis yang masuk akal tetapi tidak didukung. Mitigasi: wajibkan constraint evidence-first dan blokir klaim tanpa kecocokan sumber.
Kegagalan pemformatan model: mismatch skema atau JSON terpotong dari hasil generasi. Mitigasi: validasi skema yang ketat dan retry dengan konteks yang dipersempit.
Lomba penerbitan gandaPekerja bersamaan dapat menerbitkan artefak parsial. Mitigasi: kunci idempotensi job, transisi state per-baris (pending -> drafting -> validated -> published).
Regresi rendering: markdown tidak valid atau transformasi HTML tidak aman. Mitigasi: jalur marked konversi yang deterministik dan pengujian output HTML yang terkait dengan manifest contoh.
Ilusi cacheData dinamis yang kadaluarsa dalam output server dapat menggeser sinkronisasi teks yang dipublikasikan dan indeks sumber. Mitigasi: selaraskan strategi rendering rute dengan kebijakan freshness runtime yang eksplisit dan hindari cache implisit saat freshness bukti diperlukan.

Catatan implementasi

Untuk rollout praktis, perlakukan ini sebagai kontrak publikasi:

Definisikan tabel sumber di Drizzle dengan batasan eksplisit: keunikan URL berdasarkan host/path kanonik, enum status ambil, dan kolom checksum.
Gunakan jalur driver yang kompatibel dengan Neon secara konsisten dengan perilaku eksekusi serverless; dokumentasi Drizzle menjelaskan opsi khusus runtime dan neon-* opsi driver.
Dalam generasi, tegakkan kontrak output terstruktur dan gagalkan objek tidak valid sebelum rendering.
Gunakan panduan produksi Next.js untuk batas server, halaman error, caching, dan metadata SEO untuk rute artikel agar publikasi tetap teramati dan cepat.
Pertahankan blob yang dihasilkan (misalnya cover image, lampiran, export) melalui Vercel Blob dengan kebijakan akses yang eksplisit dan penamaan deterministik agar tidak terjadi tabrakan.
Emisikan pemeriksaan operasional sebelum publish: jumlah sumber minimum, keragaman sumber minimum, freshness bukti, dan tingkat penyelesaian minimum untuk klaim yang dipetakan.

Ini adalah pergeseran kunci: artikel tidak lagi dinilai dari kecerdikan model; ia dinilai dari apakah bukti dan generasi tetap tersinkronisasi di bawah kondisi retry dan redeploy.