วิเคราะห์: บริบทยาวไม่ได้ฆ่าการค้นคืนข้อมูล — แต่เปลี่ยนหน้าที่ของมันต่างหาก
หน้าต่างบริบทระดับล้านโทเคนทำให้แนวคิด 'ใส่ทุกอย่างลงในพรอมป์' กลายเป็นเรื่องที่ทำได้จริงในทางเทคนิค แต่ความแม่นยำ ความหน่วง และต้นทุน ล้วนคัดค้านแนวทางนี้ นี่คือหลักการตัดสินใจที่ใช้งานได้จริงว่าเมื่อใดควรค้นคืนข้อมูล เมื่อใดควรยัดทุกอย่างลงไป และเมื่อใดควรทำทั้งสองอย่างควบคู่กัน
คำตอบโดยย่อ
หน้าต่างบริบทขนาดใหญ่ทำให้ RAG ไม่จำเป็นอีกต่อไปหรือไม่
ไม่ใช่ แต่มันเปลี่ยนบทบาทของ RAG ไป การยัดข้อมูลจนเต็มหน้าต่างบริบทขนาดใหญ่จะทำให้ความแม่นยำลดลงสำหรับข้อมูลที่ฝังอยู่ตรงกลาง เพิ่มความหน่วงและต้นทุนในทุกคำขอ และทำให้ยากที่จะระบุว่าคำตอบมาจากแหล่งใด การค้นคืนข้อมูลยังคงเป็นทางเลือกที่เหมาะสมที่สุดสำหรับคลังข้อมูลขนาดใหญ่หรือที่เปลี่ยนแปลงอยู่เสมอ สำหรับงานใดก็ตามที่ต้องการการอ้างอิงแหล่งที่มาหรือการควบคุมสิทธิ์การเข้าถึง และสำหรับเส้นทางที่มีปริมาณการใช้งานสูงซึ่งอ่อนไหวต่อต้นทุน ส่วนบริบทยาวในปัจจุบันเหมาะที่จะนำไปใช้กับการให้เหตุผลจากเอกสารทั้งฉบับ ใช้เป็นหน่วยความจำทำงานของเอเจนต์ในแต่ละงาน และใช้เป็นขั้นตอนที่สองต่อจากการค้นคืนข้อมูลที่ได้คัดกรองขอบเขตให้แคบลงแล้ว
ประเด็นสำคัญ
- ความจุของบริบทไม่เหมือนกับการใช้ประโยชน์จากบริบท โมเดลจะดึงข้อมูลได้แม่นยำจากส่วนต้นและส่วนท้ายของหน้าต่างข้อความยาว แต่มีความแม่นยำน้อยลงเมื่อข้อมูลอยู่ตรงกลาง
- ต้นทุนและความหน่วงแปรผันตามปริมาณข้อมูลที่ส่งจริง ไม่ใช่ตามขนาดสูงสุดที่หน้าต่างรองรับได้ ขั้นตอนการดึงข้อมูลที่ช่วยลดจาก 200,000 โทเคนเหลือเพียง 4,000 โทเคน จะคุ้มค่ากับทุกคำขอที่เกิดขึ้น
- การดึงข้อมูล (retrieval) ยังคงมีความสำคัญด้วยคุณสมบัติสามประการที่บริบทยาวให้ไม่ได้ คือ การอ้างอิงแหล่งที่มา ความสดใหม่ของข้อมูล และการควบคุมสิทธิ์การเข้าถึงตามผู้ใช้แต่ละราย
- สถาปัตยกรรมที่แข็งแกร่งที่สุดในปัจจุบันไม่ใช่การเลือกอย่างใดอย่างหนึ่ง แต่คือการดึงข้อมูลเพื่อคัดกรองให้แคบลงก่อน แล้วจึงให้โมเดลใช้บริบทอย่างเต็มที่กับชุดข้อมูลที่คัดกรองแล้วนั้น
- หากคำตอบผิดพลาดเพราะไม่เคยดึงเอกสารที่ถูกต้องมาใช้ตั้งแต่แรก การประเมินที่ตัวโมเดลก็เท่ากับกำลังวัดผลผิดจุด
ทุกครั้งที่หน้าต่างบริบทมีขนาดใหญ่ขึ้นหนึ่งลำดับขั้น ก็มักมีข้ออ้างเดิมวนกลับมาอีกครั้งว่า การค้นคืนข้อมูลเป็นเพียงทางแก้ชั่วคราวสำหรับหน้าต่างขนาดเล็ก ตอนนี้หน้าต่างใหญ่แล้ว การค้นคืนข้อมูลจึงหมดความจำเป็น เพียงใส่เอกสารทั้งหมดลงในพรอมต์แล้วปล่อยให้โมเดลจัดการเอง
ข้ออ้างนี้ไม่ใช่เรื่องไร้เหตุผล ปัจจุบันเราสามารถใส่โค้ดเบสทั้งชุด อีเมลตลอดหนึ่งปี หรือสัญญากองใหญ่ลงในคำขอเดียวได้จริง เหตุที่ระบบใช้งานจริงส่วนใหญ่ยังคงค้นคืนข้อมูลไม่ใช่เพราะความเคยชิน แต่เป็นเพราะ ความจุกับการใช้ประโยชน์เป็นคนละเรื่องกัน และคุณสมบัติสามประการของการค้นคืนข้อมูลไม่ได้เกี่ยวข้องกับขนาดหน้าต่างเลย
ความจุไม่ใช่การใช้ประโยชน์
โมเดลที่รองรับหนึ่งล้านโทเค็นย่อมรับหนึ่งล้านโทเค็นได้ แต่จะ ใช้ โทเค็นเหล่านั้นอย่างทั่วถึงหรือไม่นั้นเป็นคำถามเชิงประจักษ์อีกข้อหนึ่ง และคำตอบก็สอดคล้องกันมาตั้งแต่มีการอธิบายปรากฏการณ์นี้เป็นครั้งแรก กล่าวคือ ความสามารถในการระลึกข้อมูลจะแข็งแกร่งที่สุดในช่วงต้นและท้ายของอินพุตขนาดยาว และอ่อนแอที่สุดในช่วงกลาง
ผลที่เกิดขึ้นในทางปฏิบัติชวนให้ไม่สบายใจว่า ตำแหน่งที่เอกสารปรากฏในพรอมต์มีผลต่อการที่โมเดลจะนำเอกสารนั้นไปใช้หรือไม่ โดยไม่ขึ้นกับว่าเอกสารดังกล่าวเกี่ยวข้องเพียงใด ระบบที่นำเอกสารห้าสิบฉบับมาต่อกันโดยไม่กำหนดลำดับได้เพิ่มตัวแปรด้านคุณภาพที่ไม่มีใครเฝ้าติดตาม และตัวแปรนี้จะเปลี่ยนไปทันทีที่ลำดับการต่อเอกสารเปลี่ยนแปลงในครั้งถัดไป
คำยืนยันที่มักหยิบยกมาคือผลการทดสอบหาเข็มในกองฟาง ซึ่งฝังประโยคที่มีลักษณะเฉพาะไว้ในหน้าต่างขนาดใหญ่แล้วพบได้อย่างน่าเชื่อถือ แต่การทดสอบนี้ง่ายกว่าที่เห็นมาก การค้นหาข้อความผิดแผกเพียงหนึ่งชุดเป็นงานจับคู่คำศัพท์ คำถามในโลกจริงต้องรวบรวมข้อมูลจากข้อความหลายส่วน สังเกตว่ามีสองส่วนขัดแย้งกัน หรือวินิจฉัยว่าไม่มีคำตอบอยู่เลย เกณฑ์มาตรฐานที่สร้างขึ้นเพื่อทดสอบงานในรูปแบบที่ยากกว่านี้แสดงให้เห็นอย่างสม่ำเสมอว่า บริบทใช้งานจริงที่มีประสิทธิผลมีขนาดต่ำกว่าความจุที่โฆษณาไว้อย่างมาก
ตัวเลขที่ไม่มีใครอยากคำนวณ
ต้นทุนและเวลาแฝงเพิ่มขึ้นตามสิ่งที่คุณส่ง ไม่ใช่ตามปริมาณที่คุณได้รับอนุญาตให้ส่ง
ลองพิจารณาผู้ช่วยฝ่ายสนับสนุนที่ตอบคำถามวันละหนึ่งหมื่นข้อโดยใช้ฐานความรู้ขนาด 200,000 โทเค็น การยัดฐานความรู้ทั้งหมดลงในทุกคำขอหมายถึงอินพุตวันละสองพันล้านโทเค็น ไม่ว่าจะคิดตามราคาของโมเดลแนวหน้ารายใดในปัจจุบัน ตัวเลขนี้ย่อมกลายเป็นรายการงบประมาณที่สะดุดตา ส่วนการค้นคืนเนื้อหาที่เกี่ยวข้องสี่พันโทเค็นต่อคำถามหมายถึงสี่สิบล้านโทเค็น ต่างกันถึงห้าสิบเท่าในทุกคำขออย่างต่อเนื่อง
เวลาแฝงเป็นไปตามเส้นโค้งเดียวกัน เวลากว่าจะได้รับโทเค็นแรกเพิ่มขึ้นตามความยาวของอินพุต และวิดเจ็ตสนับสนุนที่เริ่มแสดงคำตอบภายใน 900 มิลลิวินาทีย่อมเป็นผลิตภัณฑ์คนละแบบกับวิดเจ็ตที่ใช้เวลาแปดวินาที ไม่ว่าคุณภาพของคำตอบจะเป็นอย่างไรก็ตาม
การแคชพรอมต์ทำให้เรื่องนี้ซับซ้อนขึ้นในแง่ที่ควรอธิบายอย่างแม่นยำ เพราะนี่คือข้อโต้แย้งที่หนักแน่นที่สุดของฝ่ายที่สนับสนุนการยัดข้อมูลทั้งหมด เมื่อคำนำหน้าขนาดใหญ่เหมือนกันในคำขอจำนวนมาก การแคชสามารถลดต้นทุนลงได้หลายเท่าและลดเวลาแฝงได้อย่างมีนัยสำคัญ หากคลังข้อมูลของคุณใช้ร่วมกันและคงที่อย่างแท้จริง เช่น คู่มือผลิตภัณฑ์ฉบับตายตัวหรือประมวลกฎหมายฉบับตายตัว สิ่งนี้จะเปลี่ยนผลการคำนวณและยังถูกใช้งานน้อยกว่าที่ควร แต่การแคชไม่ช่วยอะไรเมื่อเนื้อหาขนาดใหญ่แตกต่างกันไปในผู้ใช้หรือคำขอแต่ละราย ซึ่งตรงกับการใช้งานระดับองค์กรส่วนใหญ่ เพราะสาระสำคัญก็คือผู้ใช้แต่ละคนอาจมีสิทธิ์เห็นเอกสารต่างกัน
คุณสมบัติสามประการที่การค้นคืนข้อมูลมี แต่บริบทไม่มี
นี่คือส่วนของข้อถกเถียงที่จะไม่เปลี่ยนแปลงแม้หน้าต่างจะใหญ่ขึ้น
การระบุแหล่งที่มา ข้อความที่ค้นคืนมามีตัวตนก่อนที่โมเดลจะเห็นเสียอีก ไม่ว่าจะเป็นรหัสเอกสาร URL เลขหน้า หรือฉบับแก้ไข เมื่อโมเดลอ้างถึงข้อความนั้น การอ้างอิงจึงตรวจสอบได้ด้วยกลไกอัตโนมัติ ข้อความที่หย่อนลงในหน้าต่างไม่มีตัวตนเช่นนี้ และการขอให้โมเดลอ้างอิงจากมวลข้อความที่แยกแยะไม่ได้ย่อมสร้างเอกสารอ้างอิงที่ตรวจสอบยากและแต่งขึ้นได้ง่าย สำหรับการใช้งานทุกประเภทที่คำตอบผิดต้องสืบย้อนกลับไปหาแหล่งที่มาได้ ไม่ว่าจะเป็นด้านกฎหมาย การแพทย์ การเงิน หรือการกำกับดูแล เพียงเหตุผลข้อนี้ก็ชี้ขาดการออกแบบแล้ว
ความเป็นปัจจุบัน คลังข้อมูลเปลี่ยนแปลงอยู่เสมอ ดัชนีค้นคืนข้อมูลอัปเดตได้ด้วยการเขียนแถวข้อมูลใหม่ ส่วนพรอมต์ที่ยัดข้อมูลทั้งหมดต้องอัปเดตด้วยการสร้างเพย์โหลดใหม่ทั้งชุดแล้วส่งซ้ำ เมื่อฐานความรู้เปลี่ยนแปลงทุกชั่วโมง วิธีหนึ่งเป็นงานเบื้องหลัง ส่วนอีกวิธีเป็นต้นทุนที่ต้องจ่ายในทุกคำขอ
การควบคุมการเข้าถึง ข้อนี้เป็นปัจจัยที่กำหนดสถาปัตยกรรมระดับองค์กรส่วนใหญ่อย่างเงียบๆ ผู้ใช้แต่ละคนได้รับอนุญาตให้เห็นเอกสารต่างกัน ในระบบค้นคืนข้อมูล สิทธิ์เป็นตัวกรองที่ใช้ขณะส่งคำค้น ก่อนข้อความใดๆ จะไปถึงโมเดล จึงเป็นขอบเขตการอนุญาตสิทธิ์แบบปกติที่ตรวจสอบย้อนหลังได้ ส่วนในระบบยัดข้อมูลทั้งหมด การตัดสินใจเรื่องสิทธิ์ต้องเกิดขึ้นระหว่างการประกอบเพย์โหลด และความผิดพลาดเพียงครั้งเดียวหมายความว่าเอกสารลับของผู้ใช้คนหนึ่งเข้าไปอยู่ในพรอมต์ของผู้ใช้อีกคนแล้ว เมื่อข้อมูลเข้าไปอยู่ในหน้าต่าง การควบคุมขั้นปลายใดๆ ก็ไม่อาจทำให้ระบบลืมว่าเคยเห็นข้อมูลนั้นได้
งานที่บริบทยาวทำได้ดีกว่าอย่างแท้จริง
ข้อผิดพลาดในทางตรงกันข้ามคือการสรุปว่าการค้นคืนข้อมูลชนะเสมอ หน้าต่างขนาดใหญ่เหนือกว่าอย่างเด็ดขาดสำหรับงานบางประเภทที่มีจำนวนเพิ่มขึ้นเรื่อยๆ
การให้เหตุผลจากสิ่งประดิษฐ์ทั้งชิ้น ไม่ว่าจะเป็นการสรุปสัญญาทั้งฉบับ การไล่หาจุดบกพร่องทั่วทั้งโค้ดเบส หรือการเปรียบเทียบเอกสารยาวสองฉบับทีละข้อ การแบ่งเป็นส่วนย่อยทำลายโครงสร้างที่งานเหล่านี้ต้องพึ่งพาโดยตรง หากคำถามเกี่ยวข้องกับภาพรวมของสิ่งนั้น การค้นคืนข้อมูลจะมอบเพียงเศษเสี้ยวของข้อโต้แย้งที่คุณจำเป็นต้องเห็นอย่างครบถ้วน
หน่วยความจำใช้งานของเอเจนต์ เอเจนต์ที่ดำเนินงานมาถึงขั้นตอนที่สี่สิบย่อมแบกประวัติของตนเองมาด้วย ทั้งผลลัพธ์จากเครื่องมือ การให้เหตุผลระหว่างทาง และไฟล์ที่อ่านมาแล้ว นี่คือบริบทที่สะสมขึ้น ภายใน เซสชัน และไม่มีอยู่ในดัชนีค้นคืนข้อมูล หน้าต่างที่ใหญ่ขึ้นช่วยยืดระยะเวลาที่เอเจนต์ทำงานต่อได้โดยตรง ก่อนจะต้องบีบอัดการตัดสินใจก่อนหน้านี้
การอ่านจำนวนน้อยแต่มีเดิมพันสูง เมื่องานทำงานเพียงไม่กี่สิบครั้งต่อวัน และความถูกต้องสำคัญกว่าต้นทุนต่อครั้ง ความเรียบง่ายของการใส่ทุกอย่างลงในพรอมต์ก็คุ้มค่าที่จะจ่าย ไม่ใช่ทุกระบบที่จำเป็นต้องมีดัชนี
สถาปัตยกรรมที่ชนะจริง
เมื่อวางกรอบให้ต้องเลือกอย่างใดอย่างหนึ่ง นี่คือการแบ่งขั้วที่ผิด รูปแบบที่แข็งแกร่งที่สุดในปัจจุบันใช้ทั้งสองวิธีตามลำดับ
ค้นคืนให้กว้าง แล้วอ่านให้เต็มที่ ใช้การค้นคืนข้อมูลเพื่อจำกัดคลังข้อมูลขนาดใหญ่ให้เหลือชุดตัวเลือก แต่แทนที่ระบบรุ่นเก่าจะส่งข้อความย่อยสามส่วน ส่วนละ 500 โทเค็น ให้ส่งเอกสารฉบับเต็มยี่สิบฉบับ การค้นคืนข้อมูลทำงานที่ตนถนัด นั่นคือการคัดเลือกภายใต้การควบคุมการเข้าถึงโดยยังรักษาข้อมูลแหล่งที่มาไว้ ส่วนบริบทยาวทำงานที่ตนถนัด นั่นคือการให้เหตุผลจากเนื้อหาโดยไม่ต้องแบ่งแยกอย่างฝืนธรรมชาติ
แนวทางนี้พลิกกลับสมมติฐานที่ฝังอยู่ในโค้ด RAG รุ่นเก่าจำนวนมากว่า ส่วนย่อยควรมีขนาดเล็กเพราะหน้าต่างมีจำกัด แต่ตอนนี้หน้าต่างไม่ได้ขาดแคลนอีกต่อไป แบ่งส่วนเพื่อคุณภาพการค้นคืน ไม่ใช่เพื่องบประมาณของหน้าต่าง ค้นคืนในระดับความละเอียดที่ทำให้การจับคู่แม่นยำ แล้วขยายผลลัพธ์แต่ละรายการให้เป็นหัวข้อหรือเอกสารฉบับเต็มก่อนส่งเข้าไปในพรอมต์
แนวปฏิบัติย่อยอีกสองข้อมีความสำคัญมากกว่าเดิม จัดลำดับอย่างตั้งใจ เมื่อคำนึงถึงผลของตำแหน่ง ข้อความที่ได้คะแนนสูงสุดควรอยู่บริเวณขอบของบริบทที่ประกอบขึ้น ไม่ใช่ตรงกลาง และ ติดป้ายกำกับข้อความทุกส่วน ด้วยรหัสแหล่งที่มาในพรอมต์ เพื่อให้การอ้างอิงยังคงเป็นกระบวนการเชิงกล แทนที่จะต้องฝากความหวังไว้กับความสุจริตของโมเดล
ประเมินองค์ประกอบให้ถูกจุด
นิสัยในการวินิจฉัยเพียงข้อเดียวช่วยป้องกันความพยายามสูญเปล่าได้เป็นส่วนใหญ่ เมื่อคำตอบผิด ให้ตรวจสอบก่อนว่าเอกสารที่จำเป็นอยู่ในบริบทหรือไม่
หากไม่มีอยู่ แสดงว่าขั้นตอนค้นคืนข้อมูลล้มเหลว และการเปลี่ยนโมเดลก็แก้ไม่ได้ หากเอกสารอยู่ในบริบทแล้วแต่โมเดลยังตอบผิด นั่นคือปัญหาในขั้นตอนสร้างคำตอบ และเมื่อนั้นคำถามเรื่องขนาดหน้าต่าง การจัดลำดับ และโครงสร้างพรอมต์จึงจะมีความเกี่ยวข้อง ระบบที่วัดเฉพาะคุณภาพตั้งแต่ต้นจนจบไม่สามารถแยกปัญหาสองประเภทนี้ออกจากกันได้ และทีมที่ดูแลระบบดังกล่าวมักใช้เวลาหลายเดือนสลับเปลี่ยนโมเดลเพื่อแก้ดัชนีที่เสีย
สรุปสั้นๆ คือ บริบทยาวได้ขจัดข้อจำกัดที่เคยทำให้การค้นคืนข้อมูลเป็นสิ่งจำเป็น แต่เหตุผลอื่นทั้งหมดในการค้นคืนข้อมูลยังคงอยู่ครบถ้วนดังเดิม ระบบใช้งานจริงส่วนใหญ่จะใช้ทั้งสองอย่างต่อไป และโจทย์การออกแบบที่น่าสนใจได้เปลี่ยนจาก ควรค้นคืนข้อมูลหรือไม่ ไปเป็น เมื่อค้นคืนมาแล้ว ควรมอบให้โมเดลมากเพียงใด
คำถามที่พบบ่อย
- 'lost in the middle' คืออะไร
- คือรูปแบบที่พบว่าโมเดลจดจำข้อมูลที่อยู่ใกล้จุดเริ่มต้นหรือจุดสิ้นสุดของข้อความอินพุตยาวได้แม่นยำกว่าข้อมูลที่อยู่ตรงกลาง นั่นหมายความว่าตำแหน่งของเอกสารในพรอมป์ต์มีผลต่อการที่โมเดลจะนำไปใช้หรือไม่ โดยไม่ขึ้นกับความเกี่ยวข้องของเนื้อหานั้นแต่อย่างใด
- การทดสอบแบบงมเข็มในมหาสมุทร (needle-in-a-haystack) เพียงพอที่จะเชื่อมั่นในหน้าต่างบริบทยาวได้หรือไม่
- ไม่เพียงพอ การค้นหาประโยคเดี่ยวที่ถูกฝังไว้อย่างชัดเจนนั้นเป็นงานที่ง่ายกว่ามากเมื่อเทียบกับการรวบรวม เปรียบเทียบ หรือให้เหตุผลข้ามข้อความหลายส่วนที่กระจัดกระจายอยู่ในหน้าต่างเดียวกัน ซึ่งเป็นสิ่งที่คำถามจริงในการใช้งานต้องการ
- เมื่อใดที่การใส่เอกสารทั้งฉบับลงไปทั้งหมดจึงเป็นทางเลือกที่ถูกต้อง
- เมื่อชุดข้อมูลมีขนาดเล็กและไม่เปลี่ยนแปลงบ่อย เมื่อคำถามจำเป็นต้องใช้เอกสารทั้งฉบับจริงๆ และเมื่อปริมาณการใช้งานต่ำพอจนต้นทุนต่อคำขอไม่ใช่ปัญหา กรณีเช่นการตรวจสอบสัญญา การวิเคราะห์โค้ดเบสเดียว และการอ่านเชิงลึกแบบครั้งเดียว ล้วนเข้าข่ายนี้
- การแคชพรอมป์ต์ (prompt caching) ช่วยตัดประเด็นเรื่องต้นทุนออกไปได้หรือไม่
- ช่วยลดต้นทุนได้มากสำหรับส่วนนำหน้าที่คงที่และถูกใช้ซ้ำในหลายคำขอ ซึ่งเป็นการปรับให้เหมาะสมที่มีประโยชน์จริงแต่ยังถูกใช้ประโยชน์น้อยเกินไป แต่วิธีนี้ไม่ช่วยเมื่อเนื้อหาขนาดใหญ่แตกต่างกันไปในแต่ละผู้ใช้หรือแต่ละคำขอ และไม่ได้แก้ปัญหาเรื่องความแม่นยำหรือการอ้างอิงแหล่งที่มา
- การอ้างอิงแหล่งที่มาทำงานอย่างไรเมื่อไม่มีการดึงข้อมูล
- จะอ่อนแอกว่ามาก การให้โมเดลอ้างอิงจากข้อความจำนวนมากที่ไม่มีการติดป้ายกำกับในหน้าต่างของมัน จะได้การอ้างอิงที่ยากต่อการตรวจสอบด้วยกลไกอัตโนมัติ ขณะที่การดึงข้อมูลจะกำหนดอัตลักษณ์ให้กับทุกข้อความก่อนที่โมเดลจะได้เห็น ซึ่งเป็นสิ่งที่ทำให้การอ้างอิงนั้นตรวจสอบได้