ตรวจจับและแยกการตัดสินใจของอีกโปรเจกต์ที่ปนเข้ามา — กับดักของเอเจนต์และ RAG ที่ข้ามหลายระบบ

บทนำ

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

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

ทำไมความทรงจำร่วมจึงแข็งแกร่ง และทำไมจึงอันตราย

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

เอเจนต์ข้ามระบบ ──▶ ค้นความทรงจำร่วม: "แนวทาง MVP ของหน้าจอฝั่งลูกค้า"
                          │  ดึงความทรงจำที่ความหมายใกล้
        ┌─────────────────┴─────────────────┐
   การตัดสินใจของแพลตฟอร์ม            กำลังทำงานฝั่งธนาคาร
   "ไม่สร้างหน้าจอละเอียด               │
    เลย์เอาต์ตายตัว รองรับทีหลัง" ─(รั่ว)─▶ ถูกเขียนลงเอกสารออกแบบของธนาคาร
                                          ราวกับเป็นการตัดสินใจของธนาคาร ×

สิ่งที่การค้นหาคืนคือความทรงจำที่ “ความหมายใกล้” ส่วน “เป็นการตัดสินใจของโปรเจกต์ไหน” ไม่ได้ติดมาด้วย ฝั่งที่ดึงมาจึงเข้าใจต้นทางผิดถ้าไม่ดู

# เมื่อเอเจนต์ข้ามระบบดึงความทรงจำร่วม (อันตรายถ้าไม่ดูต้นทาง)
query : "แนวทาง MVP ของหน้าจอฝั่งลูกค้า"
 └─ hit : "ไม่สร้างหน้าจอละเอียด เลย์เอาต์ตายตัว รองรับทีหลัง"  [ต้นทาง: แพลตฟอร์ม]
          ↑ ความหมายใกล้ แต่ธนาคารไม่ได้ตัดสินใจแบบนี้

(MVP = เวอร์ชันแรกที่ส่งมอบคุณค่าด้วยสิ่งที่น้อยที่สุด แนวทางที่ลดการสร้างละเอียด แล้วปล่อยของที่ใช้ได้ออกมาก่อน)

มันรั่วจริง ๆ

ฝั่งแพลตฟอร์มมีแนวทาง MVP เฉพาะของโปรเจกต์: “สำหรับ MVP ไม่สร้างหน้าจอละเอียด มือถือตรึงแนวตั้ง เว็บตรึงขนาดเท่ากัน การรองรับ responsive เลื่อนไปเฟสถัดไป” เลย์เอาต์ความกว้างตายตัวแคบ ๆ คือผลของแนวทางนี้

แต่ขณะสร้างหน้าจอฝั่งลูกค้าของระบบธนาคาร ความกว้างตายตัวแคบ ๆ เดียวกันก็ถูกนำมาใช้ และมันถูกเขียนลงในเอกสารออกแบบของระบบธนาคารเองในฐานะ “แนวทางการสร้างละเอียดของ MVP” ฝั่งธนาคารไม่ได้ตัดสินใจแบบนั้น

[รั่ว]     "แนวทางการสร้างละเอียด" ของแพลตฟอร์มถูกเขียนลงเอกสารออกแบบของธนาคารในฐานะการตัดสินใจของธนาคาร ×
[ที่ควรเป็น] การตัดสินใจนั้นเฉพาะของแพลตฟอร์ม → เอาออกจากเอกสารออกแบบของธนาคาร กลับสู่แนวทางของธนาคารเอง ✓

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

ทำไมจึงเกิดขึ้น

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

(ผมเหยียบกับดัก “ความหมายใกล้ ≠ ผสมได้” เดียวกันในฝั่งผลิตภัณฑ์ของการค้นหาแบบเวกเตอร์ด้วย — ที่ผลงานคนละหมวดปนเข้าไปในการแนะนำ อยู่ใน การค้นหาแบบเวกเตอร์แอบผสม “สิ่งที่ความหมายใกล้เคียง” เข้ามาเอง)

จะอุดอย่างไร

มาตรการคือการแยกบทบาทของสิ่งที่ใส่ลงความทรงจำ และการตรวจสอบก่อนนำมาใช้ ก่อนอื่น ใส่เฉพาะ “ปัญญา” ที่ข้ามได้ลงในความทรงจำร่วม และเก็บ “ข้อเท็จจริง” เฉพาะของโปรเจกต์ไว้ที่ฝั่งโค้ด/เอกสารออกแบบ

# การแยกสิ่งที่ใส่ลงความทรงจำ (วินัยการปฏิบัติงาน)
ความทรงจำร่วม   … ปัญญาที่ถ่ายโอนได้ (หลักการออกแบบ บทเรียนความล้มเหลว ความรู้เทคนิค)  ← ข้ามได้
โค้ด/เอกสารออกแบบ … ข้อเท็จจริงเฉพาะโปรเจกต์ (ค่าตั้งค่า ID การตัดสินใจของโปรเจกต์นั้น)  ← ห้ามข้าม

จากนั้น การตัดสินใจที่ความทรงจำเสนอมา ให้ตรวจกับเอกสารออกแบบของโปรเจกต์นี้ก่อนนำมาใช้ ผ่านขั้นนี้ในด่านตรวจก่อนลงมือ

# ด่านตรวจก่อนลงมือ (ตัดตอน) — วางเอกสารออกแบบไว้เหนือความทรงจำ
・แม้ความทรงจำบอกว่า "ตัดสินใจไว้แล้ว" ก็นำมาใช้หลังยืนยันว่ามีอยู่จริงในเอกสารออกแบบนี้เท่านั้น
・ถ้าเมโม/ความทรงจำขัดกับเอกสารออกแบบ เอกสารออกแบบชนะ
・ความทรงจำที่ดึงมา ให้ดูโปรเจกต์ต้นทาง (ยิ่งหัวข้อคล้าย ยิ่งสงสัยการปนจากอีกโปรเจกต์)

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

”ความหมายใกล้” ไม่ใช่ “การตัดสินใจของโปรเจกต์นี้”

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

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