บันทึกวิศวกรรมของ Naly: การเขียนบทความแบบเสริมด้วยการค้นคืนข้อมูลพร้อมแหล่งข้อมูลที่บันทึกถาวร

บทคัดย่อ

การสร้างข้อความแบบเสริมด้วยการค้นคืนข้อมูลทำให้ไปป์ไลน์บทความของ Naly มีความจำด้านการวิจัยที่ใหม่กว่าและตรวจสอบได้มากกว่าการพึ่งพาน้ำหนักโมเดลเพียงอย่างเดียว สำหรับงานบันทึกวิศวกรรมหรือบทความข่าวกรองตลาดแต่ละชิ้น ระบบสามารถค้นหาเว็บและ arXiv เก็บ URL ของแหล่งข้อมูลไว้กับอาร์ติแฟกต์ที่สร้างขึ้น ขอให้โมเดลตอบก่อน แล้วเรนเดอร์ผลลัพธ์เป็น HTML ประเด็นไม่ใช่การทำอัตโนมัติเพื่อการทำอัตโนมัติเอง แต่คือการเผยแพร่ข้อกล่าวอ้างที่ผู้อ่านสามารถตรวจสอบย้อนกลับได้

วิทยานิพนธ์นี้เรียบง่าย: RAG สำหรับการเขียนบทความควรถูกปฏิบัติเป็นระบบหลักฐานระดับโปรดักชัน ไม่ใช่รูปแบบแชตบอต แชตบอตอาจได้รับการให้อภัยสำหรับคำตอบที่อ่อนแอ แต่บทความที่เผยแพร่แล้วจะกลายเป็นพื้นผิวความไว้วางใจที่คงอยู่ยาวนาน ดังนั้นการติดตั้งใช้งานของ Naly จึงต้องมีหลักไม่แปรเปลี่ยนสามข้อ: ค้นคืนข้อมูลก่อนร่างเนื้อหา, บันทึกแหล่งข้อมูลที่ยังคงอยู่หลังเผยแพร่, และตัวเรนเดอร์ที่รักษา Markdown ให้อ่านง่ายพร้อมหลีกเลี่ยง HTML ที่ไม่ปลอดภัย

ตำแหน่งของมันใน Naly

งานบทความของ Naly อยู่ระหว่างการได้มาซึ่งงานวิจัยและการเผยแพร่สู่สาธารณะ งานเริ่มจากหัวข้อที่เลือก สร้างเจตนาการค้นหา ดึงวัสดุจากเว็บและ arXiv ทำให้ผลลัพธ์อยู่ในรูปบันทึกแหล่งข้อมูลมาตรฐาน จากนั้นขอให้โมเดลเขียนบทความแบบตอบก่อนจากชุดหลักฐานที่มีขอบเขตนั้น ผลลัพธ์ไม่ใช่แค่ร้อยแก้ว แต่เป็นชุดรวม: เนื้อหา Markdown, HTML ที่เรนเดอร์แล้ว, URL แหล่งข้อมูล, ชื่อแหล่งข้อมูล, ประเภทแหล่งข้อมูล และเมทาดาทาที่เพียงพอจะอธิบายได้ว่าเหตุใดจึงใช้แต่ละแหล่ง

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

ชั้น RAG ควรอยู่ก่อนการร่าง ไม่ใช่หลังจากนั้น การแนบการอ้างอิงภายหลังอ่อนแอกว่า เพราะโมเดลได้สร้างข้อกล่าวอ้างไปแล้ว ในการออกแบบที่แข็งแรงกว่า การค้นคืนข้อมูลจะจำกัดบริบทการสร้าง และการสร้างจะผลิตข้อกล่าวอ้างที่ตรวจสอบกับชุดข้อมูลที่ค้นคืนมาได้ บทความที่ผู้อ่านเห็นยังคงกระชับได้ แต่อาร์ติแฟกต์ที่จัดเก็บควรรักษาร่องรอยการวิจัยไว้

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

สำหรับการเขียนบทความ โฟลว์ RAG ของ Naly เป็นไปป์ไลน์แบบแบตช์:

การเลือกหัวข้อสร้างคำถามวิจัยที่มีขอบเขต เช่น การสร้างข้อความแบบเสริมด้วยการค้นคืนข้อมูลช่วยยึดการเขียนบทความที่มีแหล่งข้อมูลรองรับได้อย่างไร
การวางแผนคำค้นขยายคำถามนั้นเป็นคำค้นเว็บ คำค้นเอกสารทางการ และคำค้น arXiv
การค้นคืนข้อมูลรวบรวมเอกสารทางการ งานวิจัยปฐมภูมิ และแหล่งอธิบายที่มีสัญญาณสูง
การทำให้เป็นมาตรฐานดึงชื่อเรื่อง URL แบบบัญญัติ ประเภทแหล่งข้อมูล บริบทการเผยแพร่หรืออัปเดตเมื่อมี และสไนปเป็ตหรือบทคัดย่อที่เกี่ยวข้อง
การเก็บแหล่งข้อมูลถาวรจัดเก็บบัญชี URL ก่อนการสร้าง เพื่อให้บทความสามารถถูกตรวจสอบย้อนหลังได้
การประกอบพรอมป์ให้หัวข้อ ข้อเท็จจริงการติดตั้งใช้งานเฉพาะของ Naly ข้อจำกัดด้านการเขียน และหลักฐานที่ค้นคืนมาแก่โมเดล
การสร้างผลิต Markdown พร้อมบทคัดย่อแบบตอบก่อน โหมดความล้มเหลวที่ระบุชัด และส่วนแหล่งอ้างอิง
การตรวจสอบยืนยันตรวจว่าทุกแหล่งอ้างอิงในบทความที่เรนเดอร์แล้วแมปกับออบเจกต์แหล่งข้อมูลที่จัดเก็บไว้
การเรนเดอร์แปลง Markdown เป็น HTML สำหรับไซต์ พร้อมใช้การทำให้ปลอดภัยและการตรวจสอบระดับโปรดักชัน

สิ่งนี้ใกล้เคียงกับรูปแบบการค้นคืนและการสร้างแบบเสริมที่อธิบายไว้ในคู่มือ RAG ของ Vercel: ค้นคืนบริบทที่เกี่ยวข้องก่อน แล้วจึงรวมกับคำถามของผู้ใช้หรืองานก่อนการสร้าง ความแตกต่างคือ Naly ไม่ได้ปรับให้เหมาะกับการสนับสนุนเชิงสนทนา แต่ปรับให้เหมาะกับการเผยแพร่ที่คงทน ซึ่ง URL ของแหล่งข้อมูลเป็นส่วนหนึ่งของโมเดลข้อมูลของบทความ

AI SDK เป็นชั้นประสานงานที่เหมาะตามธรรมชาติสำหรับงานประเภทนี้ เพราะอินเทอร์เฟซการสร้างข้อความรองรับการทำอัตโนมัติแบบไม่โต้ตอบ การเรียกใช้เครื่องมือ ผลลัพธ์หลายขั้นตอน และเมทาดาทาแหล่งข้อมูลเมื่อผู้ให้บริการส่งแหล่งข้อมูล URL กลับมา แม้เมื่อผู้ให้บริการไม่ส่งออบเจกต์แหล่งข้อมูลแบบเนทีฟ Naly ก็สามารถแนบรายการแหล่งข้อมูลที่ค้นคืนเองเข้ากับอาร์ติแฟกต์บทความ และปฏิบัติต่อแหล่งข้อมูลแบบเนทีฟของโมเดลเป็นส่วนเสริม ไม่ใช่แหล่งอำนาจหลัก

วรรณกรรมกล่าวว่าอย่างไร

สูตรตั้งต้นของ RAG โดย Lewis et al. วางกรอบปัญหาหลักได้ดี: โมเดลภาษาแบบพาราเมตริกเก็บข้อเท็จจริงไว้ในน้ำหนัก แต่การอัปเดตความรู้นั้นและการให้แหล่งที่มายังคงทำได้ยาก โมเดลแบบเสริมด้วยการค้นคืนข้อมูลของพวกเขารวมโมเดลลำดับเข้ากับดัชนีเวกเตอร์หนาแน่น และพบว่าการสร้างมีความเฉพาะเจาะจง หลากหลาย และเป็นข้อเท็จจริงมากกว่าค่าฐานที่ใช้พาราเมตริกเพียงอย่างเดียวในงานที่ต้องใช้ความรู้อย่างเข้มข้น

งานสำรวจ RAG ภายหลังโดย Gao et al. ขยายแนวคิดนั้นเป็นอนุกรมวิธาน: naive RAG, advanced RAG และ modular RAG ไปป์ไลน์บทความของ Naly ควรเป็นแบบ modular การค้นคืนข้อมูล การจัดอันดับ การเก็บแหล่งข้อมูลถาวร การสร้างพรอมป์ การสร้างข้อความ การตรวจสอบแหล่งอ้างอิง และการเรนเดอร์ เป็นหน่วยแยกกันพร้อมโหมดความล้มเหลวที่แยกกัน การปฏิบัติต่อสิ่งเหล่านี้เป็นหน่วยแยกกันทำให้ระบบดีบักง่ายขึ้นเมื่อบทความอ้างแหล่งข้อมูลที่อ่อนแอหรือพลาดแหล่งที่ดีกว่า

Self-RAG เพิ่มข้อควรระวังสำคัญ Asai et al. โต้แย้งว่าการค้นคืนจำนวน passage คงที่ ไม่ว่าจำเป็นต้องค้นคืนหรือไม่ อาจทำให้คุณภาพผลลัพธ์ลดลง สำหรับ Naly นั่นหมายความว่าการค้นคืนแบบ top-k ไม่ควรเป็นพิธีกรรม บทความสั้นเกี่ยวกับฟีเจอร์เฟรมเวิร์กที่เสถียรอาจต้องใช้เอกสารทางการและงานวิจัยหนึ่งชิ้น ส่วนบทความที่หนักด้านวรรณกรรมอาจต้องใช้แหล่ง arXiv หลายแหล่งและงานสำรวจ ความลึกของการค้นคืนควรเป็นไปตามความเสี่ยงของข้อกล่าวอ้าง

RAGChecker ให้บทเรียนด้านการประเมิน Ru et al. โต้แย้งว่าระบบ RAG ต้องมีการวินิจฉัยแบบละเอียดทั้งในส่วนการค้นคืนและการสร้าง โดยเฉพาะสำหรับคำตอบขนาดยาว สำหรับ Naly หน่วยการประเมินไม่ควรเป็นเพียงคุณภาพบทความ แต่ควรรวมถึง recall ของการค้นคืน ความเกี่ยวข้องของแหล่งข้อมูล การสนับสนุนข้อกล่าวอ้าง ความครอบคลุมของแหล่งอ้างอิง และว่ามีข้อกล่าวอ้างที่ไม่มีหลักฐานรองรับหลุดเข้าไปใน Markdown สุดท้ายหรือไม่

ข้อแลกเปลี่ยนด้านการออกแบบ

recall สูงเทียบกับ noise ต่ำคือข้อแลกเปลี่ยนหลัก การค้นคืนมากขึ้นเพิ่มโอกาสพบแหล่งข้อมูลที่ถูกต้อง แต่ก็เพิ่มโอกาสที่สไนปเป็ตอ่อนแอจะเข้าสู่พรอมป์และชี้นำโมเดลด้วย Naly ควรเลือกแนวทางเป็นขั้นตอน: รวบรวมอย่างกว้าง กรองอย่างเข้มงวด แล้วจึงย่อบริบทพรอมป์ให้กระชับ

การเก็บแหล่งข้อมูลถาวรช่วยเพิ่มความสามารถในการตรวจสอบ แต่ก็สร้างงานด้านการจัดเก็บและบำรุงรักษา URL เปลี่ยน งานวิจัยถูกแก้ไข และหน้าเอกสารย้ายที่ บันทึกที่คงทนควรรวม URL แบบบัญญัติ เวลา fetched ชื่อเรื่อง ประเภทแหล่งข้อมูล และโดยอุดมคติคือ digest ของเนื้อหาหรือขอบเขต excerpt สิ่งนี้ทำให้ Naly แยกแยะข้อผิดพลาดของโมเดลออกจากแหล่งข้อมูลที่เปลี่ยนไปได้

การเขียนแบบตอบก่อนเพิ่มคุณค่าให้ผู้อ่าน แต่ก็อาจบีบอัดความไม่แน่นอนอย่างรุนแรงเกินไป บทความควรขึ้นต้นด้วยข้อสรุป พร้อมยังคงมีส่วนภายหลังสำหรับโหมดความล้มเหลวและข้อควรระวัง สรุปแบบตอบก่อนคือจุดเข้า ไม่ใช่ใบอนุญาตให้ทำให้หลักฐานแบนราบ

HTML ที่เรนเดอร์แล้วช่วยเพิ่มการกระจายและประสบการณ์การอ่าน แต่ก็สร้างขอบเขตความปลอดภัย Marked รวดเร็วและมีประโยชน์สำหรับการแยกวิเคราะห์ Markdown แต่เอกสารของมันเตือนอย่างชัดเจนว่าไม่ได้ sanitize HTML ขาออก ตัวเรนเดอร์บทความของ Naly ควร sanitize HTML ที่สร้างขึ้นและเก็บแหล่ง Markdown ที่เชื่อถือได้ไว้ให้เล่นซ้ำได้

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

พลาดในการค้นคืน: ขั้นตอนค้นหาพบแหล่งข้อมูลที่ดูเป็นไปได้แต่ไม่ครบถ้วน สิ่งนี้มักเกิดขึ้นเมื่อ query planner แคบเกินไปหรือใช้คำผลิตภัณฑ์ที่แตกต่างจากวรรณกรรม วิธีลดความเสี่ยง: ใช้รูปแบบคำค้นหลายแบบ รวมเอกสารทางการ และกำหนดให้มีแหล่งปฐมภูมิหรือ arXiv อย่างน้อยสองแหล่งเมื่อบทความกล่าวอ้างเชิงวิจัย

การฟอกการอ้างอิง: แหล่งข้อมูลปรากฏในรายการอ้างอิง แต่ไม่ได้สนับสนุนประโยคใกล้เคียงจริงๆ สิ่งนี้แย่กว่าการไม่มีการอ้างอิง เพราะสร้างความมั่นใจเทียม วิธีลดความเสี่ยง: ตรวจสอบข้อกล่าวอ้างกับสไนปเป็ตแหล่งข้อมูล และปฏิเสธบทความที่แหล่งอ้างอิงเป็นเพียงเรื่องใกล้เคียงในหัวข้อ

การเลื่อนของแหล่งข้อมูลที่ล้าสมัย: หน้าเอกสารทางการเปลี่ยนหลังเผยแพร่ วิธีลดความเสี่ยง: เก็บเมทาดาทาแหล่งข้อมูลถาวร ณ เวลาสร้าง และบันทึกป้ายกำกับวันที่ สำหรับแหล่งข้อมูลที่ขับเคลื่อนข้อกล่าวอ้างหลัก ให้เก็บ snapshot หรือ digest เมื่อใบอนุญาตอนุญาต

การค้นคืนมากเกินไป: ชิ้นข้อมูลมากเกินไปทำให้โมเดลสรุปบริบทแทนที่จะตอบวิทยานิพนธ์ของบทความ วิธีลดความเสี่ยง: ใช้การจัดอันดับแหล่งข้อมูล ลบเอกสารที่เกือบเหมือนกันซ้ำ และจำกัดหลักฐานในพรอมป์ตามความเกี่ยวข้องกับข้อกล่าวอ้าง ไม่ใช่จำนวนดิบ

การปนเปื้อนบริบท: หน้า spam หน้า SEO ที่สร้างขึ้นอัตโนมัติ หรือสรุปคุณภาพต่ำมีอันดับเหนือวัสดุปฐมภูมิ วิธีลดความเสี่ยง: จัดอันดับเอกสารทางการ arXiv มาตรฐาน และ repository ต้นทางไว้เหนือบทวิจารณ์รอง เว้นแต่บทความจะเกี่ยวกับการตอบรับของอุตสาหกรรมโดยตรง

ความเสี่ยงจากตัวเรนเดอร์: Markdown ที่สร้างขึ้นอาจมี HTML ดิบ ลิงก์ไม่ปลอดภัย หรือตารางผิดรูป วิธีลดความเสี่ยง: sanitize HTML ที่เรนเดอร์แล้ว ทำให้ลิงก์เป็นมาตรฐาน ปฏิเสธเนื้อหาที่รันสคริปต์ได้ และรันการตรวจสอบโปรดักชันให้สอดคล้องกับคำแนะนำของ Next.js ด้านประสิทธิภาพ ความปลอดภัย เมทาดาทา และการเข้าถึง

บันทึกการติดตั้งใช้งาน

จากข้อเท็จจริง runtime ปัจจุบันของ Naly สถาปัตยกรรมที่สะอาดคือ job TypeScript ที่ใช้ ai@6.0.0-beta.105 สำหรับการประสานงานโมเดล เครื่องมือค้นคืนเว็บและ arXiv สำหรับการรวบรวมหลักฐาน Drizzle ORM กับ Neon สำหรับบันทึกบทความและแหล่งข้อมูล marked@17.0.1 สำหรับการเรนเดอร์ Markdown เป็น HTML และ Next.js 16 สำหรับพื้นผิวการเผยแพร่

ฐานข้อมูลควรปฏิบัติต่อแหล่งข้อมูลเป็นแถวชั้นหนึ่ง ไม่ใช่ blob ของข้อความ Markdown schema ที่ใช้งานได้จริงมีตารางบทความ ตาราง join ระหว่างบทความกับแหล่งข้อมูล และฟิลด์แหล่งข้อมูลสำหรับ URL ชื่อเรื่อง ประเภทแหล่งข้อมูล timestamp ที่ค้นคืนมา ตัวระบุแบบบัญญัติ เช่น arXiv ID เมื่อมี และสถานะการสกัดข้อมูล จากนั้นบันทึกบทความสามารถชี้ไปยัง Markdown, HTML ที่เรนเดอร์แล้ว, สรุป, ประเด็นสำคัญ และเมทาดาทาการเผยแพร่ได้

Vercel Blob มีประโยชน์สำหรับอาร์ติแฟกต์ขนาดใหญ่หรือผลลัพธ์การเรนเดอร์ที่ไม่เปลี่ยนรูป ขณะที่ Postgres ยังเหมาะกว่าในฐานะบัญชีที่ query ได้สำหรับแหล่งข้อมูลและเมทาดาทาบทความ การแยกนี้ทำให้ query เพื่อตรวจสอบมีต้นทุนต่ำ: แสดงบทความทุกชิ้นที่ใช้แหล่งข้อมูลหนึ่ง แหล่งข้อมูลทุกแหล่งที่บทความหนึ่งใช้ และบทความทุกชิ้นที่การสกัดแหล่งข้อมูลล้มเหลว

พรอมป์ของตัวสร้างควรกำหนดวินัยต่อแหล่งข้อมูลไว้ในรูปแบบของผลลัพธ์: ไม่มีข้อกล่าวอ้างที่ไม่มีหลักฐานรองรับ ไม่มี URL ที่แต่งขึ้น และส่วนแหล่งอ้างอิงที่ลิงก์ต้องตรงกับรายการแหล่งข้อมูลที่บันทึกถาวร โมเดลสามารถเขียนร้อยแก้วได้ลื่นไหล แต่งานควรเป็นเจ้าของความจริงของแหล่งข้อมูล หากโมเดลปล่อยแหล่งอ้างอิงที่ไม่ได้ค้นคืนมา validator ควรทำให้บทความล้มเหลวแทนที่จะเผยแพร่อย่างเงียบๆ

สุดท้าย พฤติกรรมระดับโปรดักชันสำคัญ Next.js มี server components, code splitting, prerendering และค่าเริ่มต้น caching อยู่แล้ว แต่ไปป์ไลน์เนื้อหาที่สร้างขึ้นยังต้องมีการจัดการข้อผิดพลาด การตรวจสอบความปลอดภัย เมทาดาทา และการใส่ใจ Core Web Vitals อย่างชัดเจน RAG ช่วยให้ Naly เขียนด้วยหลักฐาน วิศวกรรมโปรดักชันทำให้แน่ใจว่าหลักฐานนั้นไปถึงผู้อ่านได้อย่างรวดเร็ว ปลอดภัย และซ้ำได้