Blog

Retrieval-augmented generation for source-backed article writing

Mga Tala sa Inhinyeriya ng Naly: Source-First na Drafting ng Artikulo gamit ang RAG para sa Matatag at Nai-audit na Paglalathala

Tinutukoy ng paunawang ito ang arkitekturang pang-produksyon kung saan ang retrieval ay isang first-class na control plane, hindi isang prompt-time hint. Ang mga job sa artikulo ng Naly ay kumokolekta ng ebidensiya sa web at arXiv, pinapanatili ang normalisadong source facts, at pinipilit ang output ng modelo sa pamamagitan ng istrukturadong, nae-audit na kontrata bago i-render ang HTML para manatiling nakaugat sa re

June 27, 202610 sources

TL;DRAng retrieval-augmented generation (RAG) ang gumagawang nagpapalit sa pipeline ng artikulo ng Naly tungo sa source-grounded publishing system sa halip na model-memory composition. Ang bawat kahilingan ng draft ay una munang kinokolekta ang ebidensiyang mula sa web at arXiv, na-no-normalize at pinananatiling naka-persist ang source URLs, at pagkatapos ay hinihingi ng modelo na gumawa ng answer-first draft at pinal na artikulong HTML. Inililipat nito ang panganib mula sa "makakabuo ba ng hallucination ang modelo?" tungo sa "kompleto at ma-traceable ba ang retrieval layer," na nagbibigay sa mga editor ng matatag na artifacts, na-replay na mga trabaho, at mapagtatanggol na mga pahayag sa publiko.

Abstrakto

Ang RAG sa Naly ay dapat idisenyo sa paligid ng pagpapanatili ng pinagmulan at deterministic na mga kontrata. Noong Hunyo 27, 2026, ang praktikal na pagiging maaasahan ay mas kaunti nang nagmumula sa mas malaking modelo at mas nanggagaling sa kung ang mga retrieval artifacts ay maaaring i-query, ma-versyon at napatunayan bago mailathala. Iminumungkahi ng paunawang ito ang disenyo na may dalawang eroplano: isang evidence plane para sa retrieval/storage at isang generation plane para sa drafting, at ipinapaliwanag kung paano diretso nitong pinapabuti ang editorial trust at panghawak ng insidente.

Kung saan ito nakapuwesto sa Naly

Pinapatakbo ng Naly ang ito bilang production content subsystem sa loob ng Next.js 16.0.7 App Router stack (next + react), kung saan bahagi ng runtime code paths ang publication ng artikulo, hindi hiwalay na offline na hakbang ng pagsulat. Ang article-job path ang pinagdapat ipatupad ang lahat ng constraints: hindi "isinusulat" ang isang job hanggang may source records, napatunayan ang summary structure, at na-materialize na ang HTML.

Iniaayos ang stack nang maingat:

  • next@16.0.7 + Ang React Server Components ay humahawak ng job-triggered rendering sa server space, na tumutugma sa server-side output contracts para sa mga artikulo.
  • drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 magdeklara ng typed, persistent na mga job at source table para masusubaybayan ang bawat pahayag.
  • ai@6.0.0-beta.105 nagbibigay sa generation ng schema-aware na output controls.
  • marked@17.0.1 nagko-convert ng mga generated Markdown summaries tungo sa rendered HTML para sa paglalathala.
  • @vercel/blob@2.0.0 nagtatago ng mga generated assets bilang matatag na URLs para sa muling paggamit.
  • Maaaring idagdag ang Anthropic tooling bilang alternatibong model provider sa loob ng parehong kontrata, ngunit hindi bilang paliwanag na daanan palayo sa structured constraints.

Pinapalitan nito ang modelong "generate then proofread" ng isang grounded write loop: retrieval, validation, generation, rendering, at publish ay kailangang pumasa lahat bago lumabas ang artikulo.

Teknikal na mekanismo

May limang nakabalangkas na yugto ang matibay na disenyo ng Naly:

  1. Plano ng ebidensiya at orkestrasyon ng query
  • Itakda ang job spec kasama ang paksa, date window, at patakaran sa ebidensiya.
  • Patakbuhin parehong web search at arXiv search para sa mga primary sources.
  • Tanggalin ang duplicate gamit ang canonical URL at i-normalize ang protocol, host, at query string.
  1. Layer ng pagpapanatili ng pinagmulan
  • I-imbak ang metadata bawat URL (url, canonicalized URL, fetch status, fetch timestamp, titulo, excerpt, uri ng pinagmulan).
  • I-imbak ang model-facing snippets nang hiwalay sa raw payloads para deterministic ang mga rerun kahit magbago ang upstream pages.
  • Magdagdag ng per-source checksums para matukoy ang drift.
  1. Paghubog ng konteksto at mga constraint
  • Gumawa ng retrieval context na inayos ayon sa kaugnayan at kamakailang datos.
  • Humingi ng explicit source IDs sa prompt contract.
  • Pilitin ang answer-first output shape (intro claim, evidence bullets, risk caveats, uncertainty), kasama ang nakaayos na source references.
  1. Structured generation na may mahigpit na schema
  • Gamitin ang structured output para agad mabigo ang malformed o hindi sumasang-ayon sa schema na sagot at maretry ito gamit ang mas mahigpit na konteksto.
  • Panatilihin ang generation sa loob ng server context at i-reject ang mga draft na nag-aangkin ng hindi sinusuportahang facts na walang mapped source IDs.
  1. I-render, ilathala, at i-verify
  • I-convert ang napatunayang markdown tungo sa HTML at i-persist ang markdown + HTML.
  • I-cache lamang ang final output pagkatapos ng matagumpay na validation.
  • I-emit ang analytics at audit fields: bilang ng source, rejected claims, bilang ng retry, at generation latency.

Ang pinakamahalagang pagbabago sa disenyo ay ang paghihiwalay ng mga alalahanin: magkaiba ang failure domains ng retrieval quality at generation quality na may magkaibang metrics. Nakatugma ang Next.js Server Components sa paghahating ito dahil maaaring manatiling deterministic ang rendering habang nangyayari ang retrieval at generation sa kontroladong async tasks.

Ano ang sinasabi ng literatura

Sinusuporta ng pinakahuling literatura sa RAG ang ganitong pattern ng arkitektura. Isang survey noong 2024 sa RAG architecture ang nagpapakita kung paano binabawasan ng retrieval-augmented systems ang fact drift sa pamamagitan ng pagkondisyon sa external evidence, ngunit binabanggit nito ang mga trade-off sa komplikasyon ng pipeline at modular coordination [Gupta et al., 2024]. Idinagdag ng follow-up survey noong 2025 na ngayon ang robustness ay umaasa sa adaptive retrieval, decoding control, at end-to-end evaluation, kaysa sa kalidad ng generation lamang [Sharma, 2025].

Para sa production quality control, malinaw na hinahati ng 2025 evaluation-focused survey ang pagsuri sa internal retriever/generator metrics at external system metrics; ang decomposition na ito ay lalo pang kapaki-pakinabang para sa article pipelines dahil ang "bad article" ay maaaring ibig sabihin na maling pagpili ng source kahit mataas ang quality ng wika [Gan et al., 2025]. Ang gawaing nakatuon sa groundedness ay lumipat din sa mga detection layer na nag-uuri ng suporta ng claim gamit ang retrieved context at NLI-style checks, na nagpapalakas sa praktikal na halaga ng post-generation validation [Gerner et al., 2025].

Sa madaling salita, nagkakaisa ang mga papel sa iisang tesis: ang RAG ay hindi lamang paraan ng paglalagay ng context, ito ay isang kontrata sa inhenyeriya sa pagitan ng retrieval at generation. Kaya dapat i-optimize ng Naly ang kontrata, hindi lang ang prompt.

Mga trade-off sa disenyo

  • Freshness laban sa determinism: mas mahigpit na TTL ay nagpapababa ng staleness ngunit nagpapataas ng re-fetch cost. Ang pagpapanatili ng snapshots ay nagbibigay-daan sa deterministic rendering habang nari-revalidate pa rin ang freshness windows.
  • Recall laban sa precision sa retrieval: mas malawak na retrieval ay maaaring magtaas ng coverage ngunit nagdadala ng ingay; proteksiyon sa kalidad ng claim ang pangalawang-stage relevance filter.
  • Sobrang paghihigpit ng schema laban sa likas na daloy ng prosa: pinapabuti ng mahigpit na output schemas ang kahusayan ng makina ngunit maaaring magpigil ng malayang estilo. Ang answer-first schema pattern ay pinananatili ang readability habang nananatili ang guardrails.
  • Bilis ng static rendering laban sa auditability: pinapabuti ng pre-rendered HTML ang performance ng paghahatid at nagpapabawas ng paulit-ulit na compute, ngunit ito lamang kung ang ginagamit na source artifacts ay immutable references.
  • Komplikasyon laban sa gastos ng operasyon: bawat dagdag na hakbang ng validation (source checks, schema checks, artifact persistence) ay nagdadagdag ng latency. Mahalaga ang susunod na production guidance sa caching, route boundaries, at build-time verification para manatiling operable ito.

Mga failure mode

  • Source drift: bumabalik ang 404/soft-changes ang URLs matapos malikha ang job. Pag-iwas: canonical key + snapshot hash + fallback source chain.
  • Retrieval overreach: ang mataas na recall na mababang precision ay nagdudulot ng makatotohanang ngunit hindi sinusuportahang synthesis. Pag-iwas: mangailangan ng evidence-first constraints at i-block ang mga claim na walang source matches.
  • Model formatting failure: hindi tugma ang schema o truncated JSON galing sa generation. Pag-iwas: mahigpit na schema validation at retry na may mas maiikling context.
  • Double-publish races: maaaring mag-publish ng bahagyang artifacts ang sabayang workers. Pag-iwas: job idempotency keys, row-level state transitions (pending -> drafting -> validated -> published ).
  • Rendering regressions: may problema ang malformed markdown o hindi ligtas na HTML transforms. Pag-iwas: deterministic marked conversion path at HTML output tests na nakatali sa sample manifests.
  • Cache illusions: ang matagal na dynamic data sa server output ay maaaring magbaliw sa published text at source index. Pag-iwas: iayon ang route rendering strategy sa malinaw na runtime freshness policy at iwasan ang implicit caches kapag kailangan ang evidence freshness.

Mga tala sa pagpapatupad

Para sa praktikal na rollout, ituring ito bilang isang publication contract contract:

  • Tukuyin ang source tables sa Drizzle na may explicit constraints: natatanging URL ayon sa canonical host/path, fetch status enums, at checksum columns.
  • Gumamit ng Neon-compatible driver path nang pare-pareho sa serverless execution behavior; inilalarawan sa Drizzle docs ang runtime-specific at neon-* mga driver options.
  • Sa generation, ipatupad ang structured output contracts at mag-fail sa hindi valid na objects bago mag-render.
  • Gamitin ang production guidance ng Next.js para sa server boundaries, error pages, caching, at SEO metadata ng article routes para mapanatili ang observability at bilis ng publishing.
  • I-persist ang generated blobs (hal., cover images, attachments, exports) sa pamamagitan ng Vercel Blob gamit ang malinaw na access policy at deterministic naming para maiwasan ang collision.
  • I-emit ang operational checks bago mag-publish: minimum source count, minimum source diversity, evidence freshness, at minimum completion rate para sa mapped claims.

Ito ang pangunahing pagbabago: hindi na hinuhusgahan ang artikulo sa talas ng modelo; hinuhusgahan ito kung ang ebidensiya at generation ay nananatiling synchronized sa ilalim ng retries at redeploys.

Mga Sanggunian

Sources