เอเจนต์ที่เก่งขึ้นได้ด้วยตัวเอง: เจาะลึกการพัฒนาตัวเองของ Orkas

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

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

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

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

วงจรตั้งแต่ต้นจนจบ

ใช้งานจริงซ้ำแล้วซ้ำเล่า
      │  บันทึกในเครื่อง: เรียกเครื่องมือใด มีข้อผิดพลาดหรือไม่ ถูกแก้ไขหรือไม่
      ▼
   สัญญาณสะสม
      │  สกัดสัญญาณจากบทสนทนา ณ จุดนั้น เก็บทั้งหมดไว้บนอุปกรณ์
      ▼
  ตัดสินใจว่าควรทบทวนหรือไม่
      │  ให้คะแนนถ่วงน้ำหนักหลายสัญญาณ เริ่มเมื่อเกินเกณฑ์เท่านั้น ไม่นับปัญหาเครือข่ายชั่วคราว
      ▼
   ทบทวนอยู่เบื้องหลัง
      │  ไม่ใช่ทุกเทิร์น แต่ทำเป็นระยะ โดยเลือกเอเจนต์ที่เข้าเกณฑ์
      ▼
  กลั่นออกมาเป็นสองสิ่ง
      │  ① "ทักษะ" ที่ใช้ซ้ำได้   ② "ความเข้าใจ" ตัวเอง
      ▼
  นำเข้าอัตโนมัติในเทิร์นถัดไป
      └──────────► กลับไปด้านบน วนต่อไป

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

ขั้นที่ 1: สังเกตตัวเองด้วยต้นทุนแทบเป็นศูนย์

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

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

ส่วน "ถูกแก้ไขหรือไม่" น่าสนใจอยู่เล็กน้อย มันเป็นการตัดสินด้วยกฎประมาณการภายในเครื่องล้วน ๆ โดยจับคู่ถ้อยคำบางแบบในข้อความบนอุปกรณ์ของคุณ เช่น ภาษาจีนว่า "不对" / "应该是" / "重新" หรือภาษาอังกฤษที่แปลว่า wrong, actually, instead มันไม่ได้มุ่งให้แม่นยำ เพราะเป็นเพียง สัญญาณ ไม่ใช่คำตัดสิน และการแจ้งผิดเป็นครั้งคราวก็ยอมรับได้ เพราะภายหลังจะนำไปถ่วงน้ำหนักร่วมกับสัญญาณอื่น ไม่มีการตัดสินใจจากสัญญาณนี้เพียงอย่างเดียว

ขั้นที่ 2: เมื่อไรจึงคุ้มค่าที่จะทบทวนจริง ๆ

นี่คือส่วนที่ผมคิดว่าสะท้อนความประณีตที่สุดในกลไกทั้งหมด

วิธีตรงไปตรงมาคือ "ทบทวนเมื่อสะสมเหตุการณ์ได้ N ครั้ง" แต่นั่นหยาบเกินไป: เครือข่ายหมดเวลาสามครั้งติดกับผู้ใช้แก้ไขสามครั้งติด ย่อมไม่ใช่เรื่องเดียวกันและไม่ควรถูกปฏิบัติเหมือนกัน Orkas ใช้ การให้คะแนนถ่วงน้ำหนักหลายสัญญาณ: ปรากฏการณ์แต่ละอย่างที่ควรใส่ใจเป็นสัญญาณที่มีน้ำหนัก นำน้ำหนักของสัญญาณที่เกิดในเทิร์นนี้มารวมกัน แล้วทบทวนก็ต่อเมื่อผลรวมเกินเกณฑ์ (ค่าเริ่มต้น 0.7)

สัญญาณหลักมีลักษณะประมาณนี้:

ตัวอย่างเช่น เทิร์นที่มีทั้งการแก้ไขจากผู้ใช้ (0.9) และความซับซ้อนบางส่วน (0.5) รวมเป็น 1.4 ซึ่งเกิน 0.7 ไปมาก จึงทบทวน ส่วนเทิร์นที่ซับซ้อนเพียงเล็กน้อย (0.5) ไม่ถึงเกณฑ์ก็ปล่อยผ่าน น้ำหนักยังสะท้อนดุลยพินิจด้วย การแก้ไขโดยตรงจากผู้ใช้ได้น้ำหนักสูงสุดที่ 0.9 เพราะเป็นข้อเสนอแนะที่มีอัตราส่วนสัญญาณต่อสัญญาณรบกวนสูงที่สุด: ผู้ใช้บอกชัด ๆ ว่าคุณผิด จึงมีโอกาสสูงมากที่จะคุ้มค่าต่อการบันทึก

ข้อยกเว้นสำคัญข้อนั้น

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

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

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

ขั้นที่ 3: ทบทวนอยู่เบื้องหลัง ไม่มาขวางหน้าคุณ

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

Orkas ย้ายการทบทวนไปทำเบื้องหลังตามรอบคงที่ กฎการจัดเวลาโดยคร่าว ๆ คือ:

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

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

ขั้นที่ 4: การทบทวนทำงานอย่างไรจริง ๆ

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

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

สิ่งที่ต้องใส่ใจจริง ๆ คือพรอมต์ มันกำหนดให้โมเดลสร้างสิ่งที่ไม่ใช่ "คำบรรยาย" แต่เป็น คำสั่งที่นำไปปฏิบัติได้ ความต่างดูเล็กน้อยแต่สำคัญมาก ลองเปรียบเทียบ:

✗ "บางครั้งเอเจนต์ตอบยืดยาวเกินไป ควรระวัง"

✓ "เมื่อตอบคำถามเกี่ยวกับสำนักงานบริหารทรัพย์สินครอบครัว ห้ามใช้หัวข้อย่อยเกิน 5 ข้อ"

✗ "ดูเหมือนผู้ใช้จะชอบคำตอบกระชับ"

✓ "เมื่อตอบในบริบทสำนักงานบริหารทรัพย์สินครอบครัว ให้บอกข้อสรุปก่อนเสมอ แล้วจึงอธิบายเหตุผล"

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

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

กลั่นออกมาเป็นสองสิ่ง

ผลลัพธ์จากการทบทวนไปอยู่สองแห่ง

อย่างแรกคือทักษะ แต่ละทักษะเป็นเอกสาร Markdown พร้อมเมทาดาทา โดยมีบล็อก frontmatter บันทึกชื่อ คำอธิบาย เวลาสร้างและอัปเดต จำนวนครั้งที่แก้เฉพาะจุด และเวลาที่ใช้ล่าสุด ตามด้วยขั้นตอนหรือประเด็นสำคัญจริง ๆ:

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

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

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

ทักษะไม่ได้มีไว้เขียนอย่างเดียว

หากเอาแต่สร้างทักษะ สุดท้ายก็สะสมเป็นกองขยะ ทักษะจึงมีวงจรชีวิตครบถ้วน

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

มีเพดานจำนวนด้วย จำนวนทักษะทั้งหมดถูกจำกัด (เช่น 200) เมื่อเต็ม การเพิ่มทักษะใหม่จะนำทักษะเก่าออกด้วย LRU (รายการที่ไม่ได้ใช้งานมานานที่สุด) เพื่อให้มีที่ว่าง การนำออกมีลำดับความสำคัญ: เอาทักษะที่ไม่เคยใช้เลยตั้งแต่สร้างออกก่อน ทักษะที่ไม่เคยถูกอ่านอาจกลั่นมาไม่ดีตั้งแต่แรก และควรเปิดทางให้สิ่งอื่น

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

รู้ได้อย่างไรว่าทักษะมีประโยชน์จริง

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

กลไกคือ เมื่อเริ่มแต่ละเทิร์น ทักษะที่มีจะปรากฏในดัชนีของพรอมต์ระบบ นับเป็น "การแสดง" หนึ่งครั้ง หากเอเจนต์อ่านทักษะจริงในเทิร์นนั้น นับเป็น "การเรียกใช้" หนึ่งครั้ง เปรียบเทียบสองอย่างนี้ก็ได้ตัวชี้วัดแรก —

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

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

ด้วยตัวเลขไม่กี่ตัวนี้ ทักษะเปลี่ยนจาก "การสะสมในกล่องดำ" เป็น "สิ่งที่ประเมินและปรับปรุงได้" การเลือกว่าควรแก้หรือลบทักษะใดจึงไม่ต้องอาศัยความรู้สึกอีกต่อไป

ปิดวงจรให้ครบ

เมื่อนำทั้งหมดมาต่อกัน หนึ่งรอบเต็มจะเป็นแบบนี้:

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

วงจรดำเนินต่อรอบแล้วรอบเล่า ไม่ใช่ทุกรอบจะก้าวกระโดด แต่ทิศทางมีทางเดียว: เข้าใจคุณมากขึ้น และทำผิดแบบเดิมน้อยลง

ข้อแลกเปลี่ยนบางอย่างที่ควรกล่าวถึง

เมื่อมองย้อนกลับไป มีการตัดสินใจสำคัญอยู่ไม่กี่ข้อในกลไกนี้

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

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

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

ใส่เบรกให้การเรียนรู้ เพดานจำนวน การนำออกแบบ LRU ขีดจำกัดความยาว หากไม่มีสิ่งเหล่านี้ ไม่ช้าก็เร็ว "การเรียนรู้อย่างต่อเนื่อง" จะกลายเป็น "การพองตัวอย่างต่อเนื่อง" การลืม การทิ้ง และการตัดส่วนเกิน สำคัญพอ ๆ กับการจำ

ส่งท้าย

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

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

หากต้องการดูเอเจนต์เฉพาะทางที่เป็นรากฐานของวงจรช้านี้ สำรวจ ทีมเอเจนต์ Orkas.