หมายเหตุด้านวิศวกรรมของ Naly: การร่างบทความ RAG แบบเน้นแหล่งข้อมูลก่อนเพื่อการเผยแพร่ที่คงทนและตรวจสอบได้

สรุปสั้น ๆการสร้างแบบเสริมการเรียกคืนข้อมูล (RAG) ทำให้ pipeline บทความของ Naly กลายเป็นระบบเผยแพร่ที่ยึดติดกับแหล่งข้อมูลแทนการประกอบจากความจำของโมเดล แต่ละคำขอร่างบทความจะรวบรวมหลักฐานเว็บและ arXiv ก่อน จากนั้นทำการ normalize และเก็บ URL แหล่งข้อมูลอย่างถาวร แล้วสั่งให้โมเดลสร้างร่างแบบ answer-first และบทความ HTML สุดท้าย ขั้นตอนนี้ย้ายความเสี่ยงจากคำถามว่า "โมเดลอาจหลอกตัวเองได้หรือไม่" ไปสู่คำถามว่า "ชั้นการเรียกคืนข้อมูลมีความครบถ้วนและตรวจสอบย้อนกลับได้หรือไม่" ทำให้บรรณาธิการได้ซ็อคลสวยที่เสถียร งานที่เรียกซ้ำได้ และข้ออ้างสู่สาธารณะที่ป้องกันได้

บทคัดย่อ

RAG ใน Naly ควรออกแบบรอบฐานของ ความคงทนของแหล่งข้อมูลและสัญญาแบบกำหนดผลลัพธ์. ในวันที่ 27 มิถุนายน 2026 ความน่าเชื่อถือเชิงปฏิบัติได้มาจากการที่สถาปัตยกรรมการเรียกคืนข้อมูลสามารถค้นหาได้ มีเวอร์ชัน และได้รับการตรวจสอบก่อนเผยแพร่ มากกว่าขนาดของโมเดล ความน่าเชื่อถือไม่ได้มาจากโมเดลที่ใหญ่ขึ้นแต่จากชั้นสถิติของข้อมูล เมื่อสร้างงานใน Naly ควรออกแบบแบบสองระนาบ: ระนาบหลักฐานสำหรับการเรียกคืน/จัดเก็บ และระนาบการสร้างสำหรับร่าง แล้วอธิบายว่ารูปแบบนี้ช่วยเพิ่มความไว้วางใจในการบรรณาธิการและการจัดการเหตุการณ์ได้อย่างไรโดยตรง

ที่อยู่ใน Naly

Naly รันส่วนนี้ในระบบย่อยผลิตเนื้อหา production ภายใน stack Next.js 16.0.7 App Router (next + react), โดยการเผยแพร่บทความเป็นส่วนหนึ่งของเส้นทางรหัส runtime แทนขั้นตอนการเขียนแยกแบบออฟไลน์ เส้นทางงานบทความคือจุดที่ต้องบังคับข้อจำกัดทั้งหมด: งานจะยังไม่ถือว่า "ถูกเขียน" จนกว่ามีบันทึกแหล่งข้อมูลอยู่ โครงสร้างสรุปผ่านการตรวจสอบ และ HTML ถูก materialized แล้ว

การจัดวางสแตกถูกออกแบบอย่างเจาะจง:

next@16.0.7 + React Server Components โฮสต์การเรนเดอร์ที่เกิดจากงานในพื้นที่เซิร์ฟเวอร์ ตรงกับสัญญาเอาต์พุตฝั่งเซิร์ฟเวอร์สำหรับบทความ
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 กำหนดตารางงานและตารางแหล่งข้อมูลแบบ typed และ persistent เพื่อให้ทุกคำอ้างสามารถติดตามย้อนกลับได้
ai@6.0.0-beta.105 ให้การสร้างข้อความพร้อมการควบคุม output ที่รับรู้ schema
marked@17.0.1 แปลงสรุป Markdown ที่โมเดลสร้างเป็น HTML ที่เรนเดอร์แล้วเพื่อเผยแพร่
@vercel/blob@2.0.0 จัดเก็บ asset ที่สร้างไว้ในรูปแบบ URL คงที่เพื่อการใช้งานซ้ำ
เครื่องมือของ Anthropic สามารถเพิ่มเป็นผู้ให้บริการโมเดลทางเลือกภายในกรอบสัญญาเดียวกันได้ แต่ไม่ใช่เป็นทางลัดเพื่อหนีจากข้อจำกัดเชิงโครงสร้าง

สิ่งนี้แทนที่โมเดลแบบ “generate แล้วตรวจแก้” ด้วย วงจรการเขียนที่ยึดหลักฐาน: การเรียกคืน การตรวจสอบ การสร้าง การเรนเดอร์ และการเผยแพร่ต้องผ่านทั้งหมดก่อนที่บทความจะแสดงผล

กลไกทางเทคนิค

ดีไซน์ของ Naly ที่แข็งแรงมีห้าขั้นตอนที่มีขอบเขตชัดเจน:

แผนหลักฐานและการควบคุมการสืบค้น

กำหนดสเปกงานด้วยหัวข้อ ช่วงวันที่ และนโยบายหลักฐาน
รันการค้นหาเว็บและ arXiv พร้อมกันสำหรับแหล่งข้อมูลหลัก
ทำ deduplicate โดย URL canonical และ normalize protocol, host และ query string

ชั้นความคงตัวของแหล่งข้อมูล

เก็บ metadata ต่อ URL (url, URL ที่ canonicalized, สถานะการดึงข้อมูล, timestamp การดึงข้อมูล, ชื่อเรื่อง, ตัวอย่างข้อความ, ประเภทแหล่งข้อมูล)
แยกเก็บ snippet ที่ใช้กับโมเดลออกจาก payload raw เพื่อให้การรันซ้ำยังคง deterministic แม้หน้าแหล่งข้อมูลต้นทางมีการเปลี่ยนแปลง
เพิ่ม checksum ต่อแหล่งข้อมูลเพื่อตรวจจับการ drift

การกำหนดบริบทและข้อจำกัด

สร้างบริบทการดึงข้อมูลที่จัดลำดับตามความเกี่ยวข้องและความใหม่
บังคับให้ prompt contract ระบุ source IDs อย่างชัดเจน
บังคับรูปแบบเอาต์พุตแบบ answer-first (intro claim, evidence bullets, risk caveats, uncertainty), พร้อมการอ้างอิงแหล่งข้อมูลตามลำดับ

การสร้างด้วย schema ที่เข้มงวด

ใช้ structured output เพื่อให้คำตอบที่ผิดรูปแบบหรือขัดแย้งกับ schema ล้มเหลวอย่างรวดเร็ว และ retry พร้อม context ที่เข้มขึ้น
เก็บการสร้างไว้ใน server context และปฏิเสธร่างที่อ้างข้อเท็จจริงที่ไม่ได้รับการรองรับโดย source IDs ที่ map แล้ว

เรนเดอร์ เผยแพร่ และตรวจสอบ

แปลง Markdown ที่ผ่านการตรวจสอบเป็น HTML และเก็บทั้ง markdown + HTML
เก็บ cache ของผลลัพธ์สุดท้ายเฉพาะหลังการตรวจสอบสำเร็จ
ส่งออกฟิลด์เชิงวิเคราะห์และการตรวจสอบ: จำนวนแหล่งข้อมูล จำนวนคำอ้างที่ถูกปฏิเสธ จำนวน retry และ latency ของการสร้าง

การเปลี่ยนผ่านทางการออกแบบที่สำคัญที่สุดคือ การแยกความรับผิดชอบ: คุณภาพของการเรียกคืนและคุณภาพของการสร้างเป็นโดเมนความล้มเหลวที่ต่างกันและมีเมตริกที่ต่างกัน Next.js Server Components เหมาะกับการแยกนี้เพราะการเรนเดอร์สามารถคงความ deterministic ได้ในขณะที่การเรียกคืนและการสร้างทำงานในงาน async ที่ควบคุมอย่างเข้มงวด

สิ่งที่วรรณกรรมกล่าวถึง

วรรณกรรม RAG ล่าสุดสนับสนุนรูปแบบสถาปัตยกรรมนี้ แบบสำรวจปี 2024 ของสถาปัตยกรรม RAG อธิบายว่าระบบเสริมการเรียกคืนข้อมูลช่วยลด fact drift โดยการปรับการสร้างให้ขึ้นกับหลักฐานภายนอก แต่ชี้ถึง trade-off เรื่องความซับซ้อนของ pipeline และการประสานโมดูล [Gupta et al., 2024] แบบสำรวจติดตามในปี 2025 ระบุว่าความทนทานตอนนี้ขึ้นกับการเรียกคืนแบบ adaptive การควบคุมการถอดรหัส และการประเมินแบบ end-to-end มากกว่าคุณภาพการสร้างอย่างเดียว [Sharma, 2025]

สำหรับการควบคุมคุณภาพ production แบบจริงจัง แบบสำรวจปี 2025 ที่เน้นการประเมินแยกการวิเคราะห์เป็นเมตริก retriever/generator ภายในและเมตริกระบบภายนอกอย่างชัดเจน การแยกประเภทเช่นนี้มีประโยชน์มากกับ pipeline บทความมาก เนื่องจาก "บทความที่ไม่ดี" อาจเกิดจากการเลือกแหล่งข้อมูลผิดแม้ภาษาเขียนจะดี [Gan et al., 2025] งานที่เน้น groundedness ยังเคลื่อนไปสู่ชั้นตรวจจับที่จัดหมวดการสนับสนุนคำอ้างด้วยบริบทที่ดึงกลับมา และตรวจสอบแบบสไตล์ NLI ซึ่งเสริมคุณค่าปฏิบัติของการตรวจสอบหลังการสร้าง [Gerner et al., 2025]

โดยสรุป งานวิจัยเหล่านี้รวมตัวกันที่ thesis เดียวกันว่า RAG ไม่ได้เป็นเพียงวิธีเติมบริบท แต่คือ สัญญาทางวิศวกรรม ระหว่างการเรียกคืนและการสร้าง ดังนั้น Naly ควรปรับปรุงสัญญานี้ ไม่ใช่เฉพาะ prompt

การพิจารณาตัดสินใจในการออกแบบ

ความสดใหม่กับความ deterministic: TTL ที่เข้มงวดลดความเก่า แต่เพิ่มต้นทุนการดึงข้อมูลใหม่ การจัดเก็บ snapshot ช่วยให้เรนเดอร์แบบ deterministic ได้พร้อมกับยังคงรอบเวลา revalidation
Recall กับ precision ในการเรียกคืน: การเรียกคืนกว้างขึ้นช่วยเพิ่มความครอบคลุม แต่แทรกสัญญาณรบกวนได้มากขึ้น ชั้นกรองความเกี่ยวข้องรอบสองช่วยปกป้องคุณภาพคำอ้าง
ความเข้มงวดของ schema กับความเป็นธรรมชาติของสำนวน: schema output ที่เข้มงวดปรับปรุงความน่าเชื่อถือของเครื่องจักร แต่ลดเสรีภาพเชิงสไตล์ได้ รูปแบบ answer-first schema ช่วยรักษาความอ่านง่ายพร้อมรักษาเกตเวย์ไว้
ความเร็วการเรนเดอร์คงที่กับความ auditability: HTML ที่ pre-rendered ช่วยเพิ่มความเร็วในการส่งมอบและลดการคำนวณซ้ำ แต่ทำได้ต่อเมื่อ artifact หลักฐานที่ใช้เป็นอ้างอิงที่ immutable
ความซับซ้อนกับต้นทุนการดำเนินงาน: ทุกขั้นตอนตรวจสอบที่เพิ่มขึ้น (การตรวจ source checks, schema checks, persistence ของ artifact) เพิ่ม latency คำแนะนำ production สมัยใหม่เรื่อง caching, route boundaries และการตรวจสอบก่อน build มีความสำคัญเพื่อให้ระบบใช้งานได้จริง

โหมดความล้มเหลว

การ drift ของแหล่งข้อมูล: URL กลับมา 404 หรือ soft-change หลังการสร้างงาน ควบคุมด้วย: คีย์ canonical + snapshot hash + fallback source chain
การเรียกคืนเกินขอบเขต: recall สูง precision ต่ำก่อให้เกิดการสังเคราะห์ที่ฟังดูน่าเชื่อถือแต่ไม่มีหลักฐานสนับสนุน ควบคุมด้วยการบังคับ evidence-first และบล็อกคำอ้างที่ไม่มี source match
ความล้มเหลวด้านรูปแบบของโมเดล: schema mismatch หรือ JSON ที่ถูกตัดตอนจากการสร้าง ควบคุมด้วยการ validate schema อย่างเข้มงวดและ retry ด้วย context ที่ลดลง
การเผยแพร่ซ้ำซ้อนแบบแข่งขัน: worker พร้อมกันสามารถเผยแพร่ artifact ได้ไม่ครบถ้วน ควบคุมด้วย job idempotency keys การเปลี่ยนแปลง state ระดับแถว (pending -> drafting -> validated -> published).
ความถดถอยในการเรนเดอร์: markdown ผิดรูปแบบหรือ HTML transform ที่ไม่ปลอดภัย ควบคุมด้วยเส้นทาง marked conversion แบบ deterministic และการทดสอบเอาต์พุต HTML ที่ผูกกับ sample manifests
ภาพลวงตา cache: ข้อมูลไดนามิกที่ค้างในผลลัพธ์เซิร์ฟเวอร์อาจทำให้ข้อความที่เผยแพร่ไม่ตรงกับดัชนีแหล่งข้อมูล ควบคุมด้วยการปรับ strategy การเรนเดอร์ route ให้ตรงกับนโยบาย freshness runtime อย่างชัดเจน และหลีกเลี่ยงแคชแอบที่จำเป็นต้องมี freshness ของหลักฐาน

หมายเหตุการนำไปใช้งาน

สำหรับการ rollout เชิงปฏิบัติ ให้คิดว่ามันคือสัญญา publication หนึ่ง:

กำหนดตารางแหล่งข้อมูลใน Drizzle พร้อมข้อจำกัดชัดเจน: ความ unique ของ URL ตาม canonical host/path สถานะการดึงข้อมูลแบบ enum และคอลัมน์ checksum
ใช้เส้นทางไดรเวอร์ที่เข้ากันได้กับ Neon แบบสม่ำเสมอตามพฤติกรรมของ serverless execution พฤติกรรม Drizzle docs อธิบายทั้ง runtime-specific และ neon-* ตัวเลือกไดรเวอร์
ในการสร้างข้อความ ให้บังคับสัญญาเอาต์พุตเชิงโครงสร้างและทำให้ล้มเหลวเมื่อ object ไม่ถูกต้องก่อน render
ใช้แนวทาง production ของ Next.js สำหรับ server boundaries, หน้า error, caching และ metadata SEO สำหรับเส้นทางบทความเพื่อให้การเผยแพร่ยังคงสังเกตได้และเร็ว
เก็บ generated blobs (เช่น ภาพปก เอกสารแนบ การ export) ผ่าน Vercel Blob ด้วยนโยบายสิทธิ์เข้าถึงที่ชัดเจนและการตั้งชื่อแบบ deterministic เพื่อป้องกันการชนกัน
ปล่อยการตรวจสอบเชิงการดำเนินงานก่อนเผยแพร่: จำนวนแหล่งข้อมูลขั้นต่ำ ความหลากหลายของแหล่งข้อมูลขั้นต่ำ ความสดใหม่ของหลักฐาน และอัตราความสมบูรณ์ขั้นต่ำสำหรับคำอ้างที่แมปแล้ว

นี่คือการเปลี่ยนแปลงหลัก: บทความไม่ถูกตัดสินจากความชาญฉลาดของโมเดลแล้ว แต่จากการที่ evidence และการสร้างคงซิงโครไนซ์กันได้ภายใต้การ retry และ redeploy