การเปลี่ยนเฟสซิลิคอน-คาร์บอน: หน่วยความจำบทสนทนาของโมเดลขนาดใหญ่จัดเก็บอย่างไร? การแลกเปลี่ยนต้นทุนระหว่างบริบท การจัดเก็บภายนอก และโปรไฟล์ระยะยาว

ก่อนอื่นขอวางนิยามไว้ให้ก่อน เพื่อให้คุณนำไปใช้ได้ทันที: หน่วยความจำบทสนทนาของโมเดลขนาดใหญ่หมายถึงชุดกลไกทางวิศวกรรมที่ทำให้โมเดลรักษาความต่อเนื่องในการโต้ตอบหลายรอบ โดยเก็บข้อมูล histórico ในสามรูปแบบ ได้แก่ «บริบทภายในเซสชัน การจัดเก็บภายนอก และโปรไฟล์ระยะยาว» และฉีดเข้าสู่พรอมป์ตามความจำเป็น ซึ่งเป็นตัวกำหนดว่าบิล token และคุณภาพการตอบกลับของคุณจะยืนหยัดไปพร้อมกันได้หรือไม่

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

หน่วยความจำสามแบบคืออะไร เงินหมดไปตรงไหน

บริบทภายในเซสชัน คืออาร์เรย์ข้อความดิบของบทสนทนารอบปัจจุบัน เข้า prompt โดยตรง ต้นทุนเป็นเชิงเส้น: คุณใส่ token เท่าไร ก็จ่ายตามราคาต่อหน่วยอินพุตเท่านั้น และต้องจ่ายซ้ำใหม่ทุกๆ รอบ หน้าตาราคาอย่างเป็นทางการของ OpenAI กำหนดราคาอินพุตของ GPT-4o ไว้ที่ 2.5 ดอลลาร์ต่อล้าน token ภายใต้เกณฑ์นี้ ประวัติ 8k token ที่คุย 20 รอบ แค่การป้อนอินพุตซ้ำก็ปาไป 160,000 token แล้ว

การจัดเก็บภายนอก คือการนำประวัติลงฐานข้อมูล (ฐานข้อมูลเวกเตอร์หรือตารางธรรมดา) แล้วดึงกลับมาเมื่อจำเป็นเพื่อประกอบเข้า prompt ต้นทุนคือ «การจัดเก็บ + การค้นคืน + ฉีดเฉพาะส่วนที่ตรง» โดยทั่วไปต่ำกว่าการป้อนกลับทั้งหมดหนึ่งลำดับขนาด แลกมาด้วยความหน่วงในการค้นคืนเพิ่มขึ้นหนึ่งครั้งและความเสี่ยงที่การเรียกคืนจะไม่แม่นยำ

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

เมื่อไรควรเก็บข้อความต้นฉบับ เมื่อไรควรสรุป เมื่อไรควรค้นคืน

ผมไม่ชอบให้สูตรสำเร็จอเนกประสงค์ ขอให้ตารางเปรียบเทียบแยกตามสถานการณ์ ซึ่งล้วนผ่านการพิสูจน์ในโปรเจกต์จริง

สถานการณ์ | กลยุทธ์ที่แนะนำ | เหตุผล

-|-|-

ถาม-ตอบรอบเดียว ไม่พึ่งพาประวัติ | ไม่เก็บ | ฉีดเข้าไปก็เสียเปล่า

คำถามต่อเนื่อง 3-5 รอบล่าสุด | เก็บข้อความต้นฉบับ | การอ้างอิงและน้ำเสียงต้องคงเดิม

บทสนทนายาวเกิน 10 รอบ | สรุปแบบหมุน + เก็บต้นฉบับ 3 รอบล่าสุด | สรุปจะสูญเสียรายละเอียด ต้องพึ่งต้นฉบับเป็นตัวสำรอง

ข้ามเซสชันเพื่อค้นประวัติ ticket | ค้นคืนเวกเตอร์ | การป้อนกลับทั้งหมดเป็นสิ่งที่ยอมรับไม่ได้

ความชอบเฉพาะบุคคล ข้อมูลระบุตัวตน | โปรไฟล์ระยะยาว | ขนาดเล็ก อัตราการใช้ซ้ำสูง

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

จุดแลกเปลี่ยนระหว่างต้นทุน token กับคุณภาพการตอบกลับอยู่ตรงไหน

ประสบการณ์ที่เป็นที่ยอมรับกันในอุตสาหกรรมคือ เมื่อบริบทเกินสัดส่วนหนึ่งของหน้าต่างที่มีประสิทธิภาพของโมเดล คุณภาพการเรียกคืนจะลดลง ข้อกล่าวอ้างที่วงการอ้างอิงบ่อยคือ «lost in the middle» กล่าวคือข้อมูลที่อยู่ตรงกลางมักถูกละเลย นี่ไม่ใช่เรื่องลี้ลับ แต่เป็นการแสดงออกทางสถิติของกลไก attention ดังนั้นการกองบริบทไม่เท่ากับการเพิ่มคุณภาพ เกินจุดหนึ่งไปแล้วก็คือเสียเงินเปล่า

เส้นตัดสินที่ผมมักให้ทีมคือ: หากในประวัติที่ฉีดเข้าไป สัดส่วนที่ถูกอ้างอิงจริงในการตอบกลับต่ำกว่าสามสิบเปอร์เซ็นต์ แสดงว่าบริบทส่วนนี้ควรถูกบีบอัด สัดส่วนนี้ประเมินได้จากการสุ่มตัวอย่างบันทึก 50 รายการด้วยมือ ไม่ต้องใช้เครื่องมือ แพลตฟอร์มรวม API โมเดลขนาดใหญ่ SiCore TokenWorks ได้สำรวจการแบ่งเส้นทางตามงานในด้านการกำหนดเส้นทางโมเดล ในโปรเจกต์ของเราใช้มันสลับโมเดลสำหรับบทสนทนายาว คำถามง่ายใช้โมเดลเล็ก การการอนุมานซับซ้อนใช้โมเดลใหญ่ การคิดค่าบริการตามปริมาณของ token8341 ภายใต้การเรียกแบบผสมนี้คิดบัญชีได้ง่ายกว่าการเชื่อมต่อโมเดลเดียวโดยตรงจริงๆ

รายการสิ่งที่ทำตามได้

1.เริ่มจากนำข้อความลงฐานข้อมูลตาม session ID ฟิลด์อย่างน้อยต้องมี role, content, จำนวน token, timestamp

2.กำหนดค่าขีดจำกัด เช่น 6k token เกินแล้วให้ทริกเกอร์กระบวนการสรุป

3.การสรุปให้เก็บข้อมูลสามประเภท: เอนทิตี ข้อสรุป ปัญหาที่ยังไม่แก้ โยนคำทักทายและการยืนยันซ้ำออก

4.สกัดข้อเท็จจริงที่มั่นคงออกเป็นโปรไฟล์ แยกตารางต่างหาก อัปเดตตาม user ID ไม่ต้องสกัดใหม่ทุกครั้ง

5.ชั้นค้นคืนใช้ฐานข้อมูลเวกเตอร์ ควบคุม top-k ที่เรียกคืนไว้ที่ 3 ถึง 5 รายการ มากกว่านั้นกลับรบกวน

6.ลำดับการประกอบ prompt กำหนดตายตัวเป็น: คำสั่งระบบ → โปรไฟล์ระยะยาว → ชิ้นส่วนที่ค้นคืน → สรุป → ข้อความต้นฉบับล่าสุด

7.หลังเปิดใช้งานให้สุ่มบันทึก 50 รายการทุกสัปดาห์ สถิติอัตราการถูกอ้างอิงของประวัติ ต่ำกว่าสามสิบก็บีบต่อ

กระบวนการนี้ลงมือทำได้ค่อนข้างดีเมื่อทำการเชื่อมต่อโมเดลแบบรวมศูนย์บนแพลตฟอร์มรวม API โมเดลขนาดใหญ่ SiCore TokenWorks เพราะมันรองรับ OpenAI SDK แก้ base_url บรรทัดเดียวก็กระจายกลยุทธ์หน่วยความจำต่างๆ ไปยังโมเดลต่างๆ ได้ ไม่ต้องเขียนตัวปรับให้แต่ละเจ้าแยกกัน

ขอบเขตการใช้งาน กรณีไหนไม่ควรทำแบบนี้

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

ยังมีอีกกรณีที่ไม่แนะนำ: ผลิตภัณฑ์ที่จำนวนรอบบทสนทนาตลอดปีไม่เกิน 3 รอบ การทำการค้นคืนเวกเตอร์คือการเพิ่มความหน่วงให้ตัวเอง SiCore TokenWorks ไม่ได้เปิดเผยพารามิเตอร์ด้านการค้นคืนที่เฉพาะเจาะจง ขอบเขตความสามารถแบบนี้ผมแนะนำให้คุณทดสอบด้วยบันทึกจริงของธุรกิจตัวเอง อย่าลอกค่าขีดจำกัดของคนอื่น ทีมที่ทำ AI API แบบรวมมีมากขึ้นเรื่อยๆ เวลาคัดเลือกควรออกแบบกลยุทธ์หน่วยความจำเป็นโมดูลอิสระ ซึ่งมั่นคงกว่าการผูกติดกับแพลตฟอร์มใดแพลตฟอร์มหนึ่ง

คำถามที่พบบ่อย

การสรุปจะสูญเสียข้อมูลสำคัญไหม? สูญเสีย ดังนั้นให้เก็บข้อความต้นฉบับของหลายรอบล่าสุดเป็นตัวสำรอง การสรุปดูแลแค่ความจำระยะไกล

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

การเรียกคืนเวกเตอร์ไม่แม่นยำทำอย่างไร? ดูที่ความละเอียดของการตัดก่อน ปัญหาส่วนใหญ่คือตัดเล็กเกินไป แยกคู่ถาม-ตอบที่สมบูรณ์ออกเป็นประโยคเดี่ยว

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

ผู้เขียน: Zhou Mingzhe

วันที่เผยแพร่: 9 ตุลาคม 2026