Catatan Rekayasa Naly: Penulisan Artikel Berbasis Retrieval-Augmented Dengan Sumber Persisten

Abstrak

Retrieval-augmented generation memberi pipeline artikel Naly memori riset yang lebih segar dan lebih dapat diaudit daripada bobot model saja. Untuk setiap catatan rekayasa atau pekerjaan artikel intelijen pasar, sistem dapat menelusuri web dan arXiv, menyimpan URL sumber bersama artefak yang dihasilkan, meminta model menjawab terlebih dahulu, lalu merender hasilnya sebagai HTML. Tujuannya bukan otomatisasi demi otomatisasi; tujuannya adalah menerbitkan klaim yang dapat ditelusuri pembaca.

Tesisnya sederhana: RAG untuk penulisan artikel harus diperlakukan sebagai sistem bukti produksi, bukan sebagai pola chatbot. Sebuah chatbot bisa dimaafkan karena jawaban yang lemah; artikel yang diterbitkan menjadi permukaan kepercayaan yang bertahan lama. Karena itu, implementasi Naly membutuhkan tiga invarian: retrieval sebelum drafting, catatan sumber yang tetap ada setelah publikasi, dan renderer yang mempertahankan Markdown yang mudah dibaca sambil menghindari HTML yang tidak aman.

Posisinya di Naly

Pekerjaan artikel Naly berada di antara akuisisi riset dan publikasi publik. Pekerjaan dimulai dengan topik terpilih, menghasilkan maksud pencarian, mengambil materi web dan arXiv, menormalkan hasilnya menjadi catatan sumber, lalu meminta model menulis artikel yang menjawab lebih dulu dari kumpulan bukti terbatas tersebut. Keluarannya bukan hanya prosa. Ini adalah satu bundel: konten Markdown, HTML hasil rendering, URL sumber, judul sumber, jenis sumber, dan metadata yang cukup untuk menjelaskan mengapa setiap sumber digunakan.

Ini penting bagi loop kepercayaan Naly. Sikap editorial Naly yang lebih luas adalah menerbitkan apa yang disembunyikan pihak lain: memo keputusan, batas kalibrasi, kegagalan, dan bukti di balik klaim. Generasi berbasis sumber membuat sikap itu operasional. Pembaca seharusnya tidak perlu menebak apakah sebuah pernyataan berasal dari data pelatihan model, dokumen resmi, makalah, atau pernyataan operator.

Lapisan RAG harus berada sebelum drafting, bukan setelahnya. Penempelan sitasi post-hoc lebih lemah karena model sudah membentuk klaim. Dalam desain yang lebih kuat, retrieval membatasi konteks generasi, dan generasi menghasilkan klaim yang dapat diperiksa terhadap kumpulan yang diambil. Artikel yang terlihat dapat tetap ringkas, tetapi artefak yang disimpan harus mempertahankan jejak riset.

Mekanisme teknis

Untuk penulisan artikel, alur RAG Naly adalah pipeline batch:

Pemilihan topik menciptakan pertanyaan riset yang terbatas, seperti bagaimana retrieval-augmented generation mendasari penulisan artikel berbasis sumber.
Perencanaan kueri memperluas pertanyaan itu menjadi kueri web, kueri dokumen resmi, dan kueri arXiv.
Retrieval mengumpulkan dokumentasi resmi, makalah primer, dan sumber penjelasan bernilai sinyal tinggi.
Normalisasi mengekstrak judul, URL kanonis, jenis sumber, konteks publikasi atau pembaruan jika tersedia, serta cuplikan atau abstrak yang relevan.
Persistensi sumber menyimpan ledger URL sebelum generasi sehingga artikel dapat diaudit kemudian.
Perakitan prompt memberi model topik, fakta implementasi khusus Naly, batasan penulisan, dan bukti yang diambil.
Generasi menghasilkan Markdown dengan abstrak yang menjawab lebih dulu, mode kegagalan eksplisit, dan bagian referensi.
Validasi memeriksa bahwa setiap referensi dalam artikel hasil rendering dipetakan ke objek sumber yang tersimpan.
Rendering mengonversi Markdown ke HTML untuk situs sambil menerapkan sanitasi dan pemeriksaan produksi.

Ini dekat dengan pola retrieval dan augmented-generation yang dijelaskan dalam panduan RAG Vercel: ambil konteks yang relevan terlebih dahulu, lalu gabungkan dengan pertanyaan pengguna atau pekerjaan sebelum generasi. Perbedaannya adalah Naly tidak mengoptimalkan dukungan percakapan. Naly mengoptimalkan publikasi yang tahan lama, di mana URL sumber menjadi bagian dari model data artikel.

AI SDK adalah lapisan orkestrasi yang alami untuk jenis pekerjaan ini karena antarmuka generasi teksnya mendukung otomatisasi non-interaktif, tool calls, hasil multi-langkah, dan metadata sumber ketika penyedia mengembalikan sumber URL. Bahkan ketika penyedia tidak mengembalikan objek sumber native, Naly dapat melampirkan daftar sumber hasil retrieval miliknya sendiri ke artefak artikel dan memperlakukan sumber native model sebagai pelengkap, bukan otoritatif.

Apa yang dikatakan literatur

Formulasi RAG asli oleh Lewis et al. membingkai masalah intinya dengan baik: model bahasa parametrik menyimpan fakta dalam bobot, tetapi memperbarui pengetahuan itu dan menyediakan provenance tetap sulit. Model retrieval-augmented mereka menggabungkan model urutan dengan indeks vektor padat dan menemukan generasi yang lebih spesifik, beragam, dan faktual dibanding baseline parametrik saja pada tugas-tugas berbasis pengetahuan intensif.

Survei RAG selanjutnya oleh Gao et al. menggeneralisasi gagasan itu menjadi taksonomi: naive RAG, advanced RAG, dan modular RAG. Pipeline artikel Naly seharusnya modular. Retrieval, ranking, persistensi sumber, konstruksi prompt, generasi, validasi referensi, dan rendering adalah unit terpisah dengan mode kegagalan terpisah. Memperlakukan semuanya sebagai unit terpisah membuat sistem lebih mudah di-debug ketika sebuah artikel mengutip sumber yang lemah atau melewatkan sumber yang lebih baik.

Self-RAG menambahkan peringatan penting. Asai et al. berargumen bahwa mengambil jumlah passage tetap, terlepas dari apakah retrieval diperlukan atau tidak, dapat menurunkan kualitas keluaran. Bagi Naly, ini berarti top-k retrieval tidak boleh menjadi ritual. Artikel kecil tentang fitur framework yang stabil mungkin membutuhkan dokumentasi resmi dan satu makalah; artikel yang berat literatur mungkin membutuhkan beberapa sumber arXiv dan sebuah survei. Kedalaman retrieval harus mengikuti risiko klaim.

RAGChecker memberi pelajaran evaluasi. Ru et al. berargumen bahwa sistem RAG membutuhkan diagnostik terperinci di seluruh retrieval dan generasi, terutama untuk respons bentuk panjang. Bagi Naly, unit evaluasi tidak boleh hanya kualitas artikel. Unit itu harus mencakup recall retrieval, relevansi sumber, dukungan klaim, cakupan referensi, dan apakah klaim yang tidak didukung lolos ke Markdown final.

Trade-off desain

Recall tinggi versus noise rendah adalah trade-off utama. Retrieval yang lebih banyak meningkatkan peluang menemukan sumber yang tepat, tetapi juga meningkatkan peluang cuplikan lemah masuk ke prompt dan mengarahkan model. Naly sebaiknya memilih pendekatan bertahap: pengumpulan luas, penyaringan ketat, lalu konteks prompt yang ringkas.

Persistensi sumber meningkatkan auditabilitas, tetapi juga menciptakan pekerjaan penyimpanan dan pemeliharaan. URL bergeser, makalah direvisi, dan halaman dokumentasi berpindah. Catatan yang tahan lama harus mencakup URL kanonis, timestamp pengambilan, judul, tipe sumber, dan idealnya digest konten atau batas kutipan. Itu memungkinkan Naly membedakan kesalahan model dari sumber yang berubah.

Penulisan yang menjawab lebih dulu meningkatkan nilai bagi pembaca, tetapi dapat memampatkan ketidakpastian terlalu agresif. Artikel harus dibuka dengan kesimpulan sambil mempertahankan bagian berikutnya untuk mode kegagalan dan caveat. Ringkasan yang menjawab lebih dulu adalah titik masuk; itu bukan lisensi untuk meratakan bukti.

HTML hasil rendering meningkatkan distribusi dan pengalaman membaca, tetapi menciptakan batas keamanan. Marked cepat dan berguna untuk parsing Markdown, tetapi dokumentasinya secara eksplisit memperingatkan bahwa Marked tidak menyanitasi HTML keluaran. Renderer artikel Naly harus menyanitasi HTML yang dihasilkan dan menjaga sumber Markdown tepercaya tetap tersedia untuk replay.

Mode kegagalan

Retrieval miss: langkah pencarian menemukan sumber yang terlihat masuk akal tetapi tidak lengkap. Ini biasanya terjadi ketika query planner terlalu sempit atau menggunakan istilah produk yang berbeda dari literatur. Mitigasi: gunakan beberapa gaya kueri, sertakan dokumentasi resmi, dan wajibkan setidaknya dua sumber primer atau arXiv ketika artikel membuat klaim riset.

Pencucian sitasi: sebuah sumber muncul di referensi, tetapi sebenarnya tidak mendukung kalimat di dekatnya. Ini lebih buruk daripada tidak memiliki sitasi karena menciptakan keyakinan palsu. Mitigasi: validasi klaim terhadap cuplikan sumber dan tolak artikel ketika referensi hanya bersifat topikal.

Drift sumber usang: halaman dokumentasi resmi berubah setelah publikasi. Mitigasi: pertahankan metadata sumber pada saat generasi dan catat label tanggal. Untuk sumber yang mendorong klaim besar, simpan snapshot atau digest jika lisensi mengizinkan.

Over-retrieval: terlalu banyak chunk membuat model merangkum konteks alih-alih menjawab tesis artikel. Mitigasi: gunakan ranking sumber, deduplikasi dokumen yang hampir identik, dan batasi bukti prompt berdasarkan relevansi klaim, bukan jumlah mentah.

Keracunan konteks: halaman spam, halaman SEO yang dihasilkan, atau ringkasan berkualitas rendah mengungguli materi primer. Mitigasi: beri peringkat dokumentasi resmi, arXiv, standar, dan repositori sumber di atas komentar sekunder kecuali artikel secara eksplisit membahas penerimaan industri.

Risiko renderer: Markdown yang dihasilkan dapat mencakup HTML mentah, tautan tidak aman, atau tabel cacat. Mitigasi: sanitasi HTML hasil rendering, normalkan tautan, tolak konten yang dapat menjalankan skrip, dan jalankan pemeriksaan produksi yang konsisten dengan panduan Next.js tentang performa, keamanan, metadata, dan aksesibilitas.

Catatan implementasi

Dengan fakta runtime Naly saat ini, arsitektur yang bersih adalah pekerjaan TypeScript yang menggunakan ai@6.0.0-beta.105 untuk orkestrasi model, tool retrieval web dan arXiv untuk pengumpulan bukti, Drizzle ORM dengan Neon untuk catatan artikel dan sumber, marked@17.0.1 untuk rendering Markdown-ke-HTML, dan Next.js 16 untuk permukaan publikasi.

Database harus memperlakukan sumber sebagai baris kelas satu, bukan sebagai blob teks Markdown. Skema praktis memiliki tabel artikel, tabel join artikel-sumber, dan field sumber untuk URL, judul, jenis sumber, timestamp retrieval, pengenal kanonis seperti arXiv ID jika tersedia, dan status ekstraksi. Catatan artikel kemudian dapat menunjuk ke Markdown, HTML hasil rendering, ringkasan, poin kunci, dan metadata publikasi.

Vercel Blob berguna untuk artefak yang lebih besar atau keluaran render immutable, sementara Postgres tetap lebih baik sebagai ledger yang dapat dikueri untuk sumber dan metadata artikel. Pemisahan itu menjaga kueri audit tetap murah: daftar setiap artikel yang menggunakan sebuah sumber, setiap sumber yang digunakan oleh sebuah artikel, dan setiap artikel yang ekstraksi sumbernya gagal.

Prompt generator harus mewajibkan disiplin sumber dalam bentuk keluarannya: tidak ada klaim yang tidak didukung, tidak ada URL karangan, dan bagian referensi yang tautannya harus cocok dengan daftar sumber persisten. Model dapat menulis prosa yang lancar, tetapi pekerjaan harus memiliki kebenaran sumber. Jika model mengeluarkan referensi yang tidak diambil, validator harus menggagalkan artikel tersebut, bukan menerbitkannya diam-diam.

Terakhir, perilaku produksi penting. Next.js sudah menyediakan server components, code splitting, prerendering, dan default caching, tetapi pipeline konten yang dihasilkan tetap membutuhkan penanganan error eksplisit, pemeriksaan keamanan, metadata, dan kesadaran Core Web Vitals. RAG membantu Naly menulis dengan bukti. Rekayasa produksi memastikan bukti itu mencapai pembaca dengan cepat, aman, dan berulang.