LightVela

การเปลี่ยนโมเดลทำให้เอเจนต์ลืมหรือไม่?

สรุป

การสลับโมเดลไม่ได้ทำให้เอเจนต์ Hermes ลืมคุณ เพราะโมเดล บุคลิก และหน่วยความจำเป็นสามชั้นที่เก็บแยกกัน: โมเดลจัดการด้านการให้เหตุผลและการสร้างสรรค์ SOUL.md กำหนดบทบาทและขอบเขตการแสดงออก และ USER.md บวก MEMORY.md (พร้อม memories/) เก็บโปรไฟล์ผู้ใช้และข้อเท็จจริงข้ามเซสชัน ใน LightVela การสลับโมเดลเพียงแค่เปลี่ยนเครื่องยนต์เบื้องหลังคำตอบถัดไป — มันไม่ได้ล้างหน่วยความจำ ไฟล์ในคลาวด์ ความสามารถ หรือการตั้งค่าภารกิจตามกำหนด และไม่ได้ย้ายประวัติการแชทไปไหน อาจรู้สึกแตกต่างอย่างแท้จริงหลังจากนั้น แต่ความแตกต่างนั้นมาจากการติดตามคำสั่ง การย่อบริบท ความยาวของคำตอบ และแนวโน้มการเรียกเครื่องมือต่าง ๆ ของโมเดลใหม่ ไม่ใช่การสูญเสียข้อมูล มีวิธีเดียวที่จะบอกความแตกต่างระหว่างพวกมัน: ถามเกี่ยวกับข้อเท็จจริงที่คุณมั่นใจว่ามันควรรู้ ถ้ามันตอบได้ แสดงว่าคุณกำลังเห็นความแตกต่างในสไตล์ ถ้ามันตอบไม่ได้ ให้ตรวจสอบชั้นหน่วยความจำ


คำพูดเปลี่ยน — ความทรงจำหายไปด้วยหรือเปล่า?

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

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

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

บทความนี้แยกสองสิ่งออกจากกันอย่างชัดเจนและให้คุณทำการทดสอบที่สามารถนำไปใช้ได้


1. ห้าชั้น: สิ่งที่ถูกแทนที่ สิ่งที่คงอยู่

ก่อนอื่น ต้องระบุอย่างชัดเจนว่าการ 'สลับโมเดล' นั้นเปลี่ยนแปลงอะไรจริง ๆ

ชั้นความรับผิดชอบที่อยู่หลังจากสลับ
โมเดลการให้เหตุผล, การวางแผน, การตัดสินใจเรียกใช้เครื่องมือ, ภาษาการตั้งค่าที่ปรับได้ถูกแทนที่
บุคลิกบทบาท, น้ำเสียง, ลำดับความสำคัญ, ขอบเขตพฤติกรรมSOUL.mdถูกเก็บไว้
โปรไฟล์ผู้ใช้พฤติกรรมการใช้ภาษา, จังหวะ, เครื่องมือที่ใช้บ่อย, สิ่งที่ควรหลีกเลี่ยงUSER.mdถูกเก็บไว้
ความจำข้อเท็จจริงข้ามเซสชัน, สถานะโครงการ, การตัดสินใจที่ผ่านมาMEMORY.md, memories/ถูกเก็บไว้
ทักษะขั้นตอนมาตรฐานที่เกิดจากสถานการณ์skills/ (แต่ละ SKILL.md)ถูกเก็บไว้

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

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


2. แล้วทำไมมันถึงรู้สึกแตกต่างอย่างแท้จริง?

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

โมเดลแตกต่างกันตามมิติที่แท้จริงเหล่านี้:

2.1 การปฏิบัติตามคำสั่ง

ข้อจำกัดใน SOUL.md ยังคงมีอยู่ แต่โมเดลใหม่อาจใช้ข้อจำกัดเหล่านี้อย่างหลวม ๆ หรือเข้มงวดมากขึ้น หากคุณเขียนว่า "เริ่มด้วยข้อสรุป" โมเดลบางตัวปฏิบัติตามทุกครั้ง ขณะที่บางตัวค่อย ๆ สร้างไปยังข้อสรุปในคำถามที่ซับซ้อน

ปรากฏว่าเป็น: บุคลิกภาพเปลี่ยนไป ความจริง: กฎยังไม่เปลี่ยน; การปฏิบัติตามเปลี่ยนไป

2.2 การย่อบริบท

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

ปรากฏเป็น: มันลืมสิ่งที่เราคุยกัน ความจริง: การเรียกคืนความจำยังทำงาน มันเพียงไม่ได้พูดซ้ำ สิ่งนี้เป็นกรณีที่มักถูกวินิจฉัยผิดว่าเป็นโรคความจำเสื่อม

2.3 ความชอบในความยาวของข้อความ

สำหรับคำถามเดียวกัน ความยาวของคำตอบสามารถแตกต่างกันหลายเท่าระหว่างโมเดล

ปรากฏว่าเป็น: มันโง่ลง หรือมันพูดมากเกินไป จริงๆ แล้ว: เป็นความยาวของข้อความเริ่มต้นที่ต่างออกไป ซึ่งสามารถปรับได้ผ่านการตั้งค่าใน USER.md หรือคำขอที่ชัดเจน

2.4 แนวโน้มการเรียกใช้เครื่องมือ

บางโมเดลชอบอ่านไฟล์หรือค้นหาก่อนตอบ ในขณะที่บางโมเดลพึ่งพาบริบทที่มีอยู่

ปรากฏเป็น: มันเลิกใช้เครื่องมือ จริงๆ: เป็นเกณฑ์ที่ต่างออกไปสำหรับการเรียกใช้งานเครื่องมือเหล่านั้น

2.5 รูปแบบภาษา

คำพูด รูปแบบการเรียก และโทนเสียงสามารถเปลี่ยนแปลงได้ทั้งหมด

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

เมื่อนำมาพิจารณารวมกัน ทั้งห้าเรื่องนี้มีคุณลักษณะหนึ่งร่วมกัน: **ทั้งห้าเกี่ยวกับ วิธีการแสดงออก ไม่ใช่ สิ่งที่มันรู้ ** นั่นคือสิ่งที่แบบทดสอบด้านล่างนี้อาศัยอยู่


3. การกระทำเพียงหนึ่งครั้งก็จบ: ถามเกี่ยวกับข้อเท็จจริงที่ทราบอยู่แล้ว

อย่าตัดสินจากความรู้สึก ใช้การทดสอบแบบกำหนดได้

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

การตีความ:

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

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


4. รายการตรวจสอบหลังสลับแบบสมบูรณ์

คำสั่งนี้ครอบคลุมกรณีส่วนใหญ่เป็นอย่างมาก

  1. ยืนยันว่าการสลับมีผล — คอนโซลควรแสดงโมเดลที่คุณเลือก วิธีนี้ช่วยตัดความเป็นไปได้ที่ "คิดว่าสลับแล้วแต่ไม่ได้สลับจริง"
  2. ส่งข้อความทดสอบสั้นๆ — ยืนยันว่าโมเดลใหม่ตอบกลับตามปกติ หากการตอบกลับครั้งแรกหลังจากสลับช้าหน่อย ให้รอสักครู่แล้วลองอีกครั้งก่อนจะเปลี่ยนอย่างอื่น
  3. ทดสอบข้อเท็จจริงที่ทราบ — ตรวจสอบชั้นความจำโดยใช้ส่วนที่ 3
  4. ตรวจสอบว่าเอกลักษณ์ยังตรงตามที่คาดหวัง — ดูว่าโทนเสียงและขอบเขตยังอยู่ใน SOUL.md หรือไม่ หากการเบี่ยงเบนชัดเจน ให้ทำให้ข้อจำกัดหลักชัดเจนมากขึ้น
  5. สุ่มตรวจสอบว่ายังสามารถใช้ทักษะได้ — ลองใช้หนึ่งทักษะในสถานการณ์ที่ตรงกันและยืนยันว่าทักษะโหลดได้
  6. ทบทวนคุณภาพผลลัพธ์ของงานตามกำหนด — สังเกตว่าคุณกำลังทบทวน คุณภาพผลลัพธ์ ไม่ใช่การซิงก์ฟิลด์โมเดล งานตามกำหนดไม่มีการตั้งค่า "โมเดลที่ยึด"
  7. ยืนยันว่าไฟล์ในคลาวด์สตอเรจยังครบถ้วน — การสลับไม่ได้เขียนทับไฟล์; นี่เป็นเพียงการตรวจสอบ

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


5. หากมันหยุดทำงานจริง ๆ หลังจากการเปลี่ยน

นี่คือปัญหาในประเภทที่แตกต่างกัน — ไม่ใช่แค่ 'ความรู้สึกต่างไป' แต่คือ 'ไม่ทำงาน' ตรวจสอบปัญหาในลำดับนี้:

  1. ยืนยันว่าการกำหนดค่าโมเดลเสร็จสมบูรณ์ — กลับไปที่การกำหนดค่าโมเดลและตรวจสอบโมเดลเป้าหมาย ข้อมูลรับรอง และการตั้งค่าผู้ให้บริการ
  2. ยืนยันความพร้อมใช้งานของบัญชีและโควต้า — ตรวจสอบว่าโมเดลสามารถใช้กับบัญชีของคุณได้และโควต้าหรือยอดคงเหลือฝั่งผู้ให้บริการเพียงพอ
  3. ทดสอบด้วยโมเดลที่ทราบว่าทำงานได้ — สิ่งนี้จะแยกความแตกต่างระหว่าง "โมเดลนี้มีปัญหา" กับ "เส้นทางทั้งหมดมีปัญหา"
  4. ตรวจสอบบันทึกล่าสุดในส่วนวินิจฉัย — หากยังไม่สามารถตอบกลับได้ ให้ใช้บันทึกเพื่อตัดสินใจว่าปัญหาอยู่ที่โมเดล การกำหนดค่า หรือภารกิจ จากนั้นจึงตัดสินใจว่าควรรีเซ็ตการกำหนดค่าโมเดลหรือไม่

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


6. เมื่อการเปลี่ยนคุ้มค่า และเมื่อไม่คุ้มค่า

การสลับมีค่าใช้จ่าย: คุณต้องปรับตัวใหม่กับสไตล์การแสดงออกที่ต่างไปและอาจต้องปรับแต่งคำสั่งใหม่ ดังนั้นจึงควรชัดเจนเกี่ยวกับแรงจูงใจ

ควรเปลี่ยน:

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

ไม่คุ้มค่าที่จะเปลี่ยน:

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

วลี "ข้อความทดสอบเดียวกัน" ในแถวที่สี่มีความสำคัญ: หากคุณเปรียบเทียบโมเดลโดยใช้คำถามที่แตกต่างกันในแต่ละครั้ง คุณกำลังวัดความยากของคำถาม ไม่ใช่ความแตกต่างของโมเดล


7. วิธีของ LightVela: ทำให้การสลับเป็นการดำเนินการที่มีความเสี่ยงต่ำ

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

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

ประเด็นสำคัญ

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

อัปเดตล่าสุดเมื่อ 2026-10-09