คืนที่ AI แก้ไขฉัน 5 ครั้ง - ปรัชญาการออกแบบเพื่อให้ RAG ส่วนตัวเป็นเพื่อนคุณเป็นเวลา 5 ปี

🔗 สารบัญซีรีส์: บทความนี้เป็น ฉบับปรัชญาการออกแบบ ของซีรีส์ บันทึกการปฏิบัติงานของผู้ช่วย AI - บันทึกการปฏิบัติสำหรับการเพิ่มรหัส Copilot / Claude ในฐานะคู่หูของคุณ

สิ่งที่คุณสามารถเรียนรู้ได้จากบทความนี้

• หลักการออกแบบเพื่อทำให้ RAG ส่วนตัว (ChromaDB + Ollama) เป็นเพื่อนคู่ใจของคุณมานานกว่า 5 ปี
• ภาพลวงตาว่า “ควรกลั่นให้สะอาด” และกับดักของมัน
• เสียงรบกวนและสัญญาณขึ้นอยู่กับผู้สังเกตการณ์ หลักการขององค์ความรู้และการดึงข้อมูล
• วิธีขัดเกลาการออกแบบของคุณด้วย AI และขีดจำกัดของมัน
• “สี่สิ่งที่คุณไม่ควรทำ” (ฉันทำทั้งหมดในคืนเดียว)

กลุ่มเป้าหมาย

• บุคคลที่ ต้องการใช้ RAG/PKM (Obsidian, Roam, Notion AI) ต่อไปเป็นเวลานาน
• ผู้ที่สนใจ “มอบหน่วยความจำภายนอกให้กับ AI”
• ผู้ที่ต้องการรีวิวการออกแบบร่วมกับ AI
• อยากหัวเราะตัวเองที่ถูก AI หลอก (ฉันคืนนี้)

---

บทนำ: คืนหนึ่งฉันต้องแก้ไข AI 5 ครั้ง

คืนหนึ่ง ฉันได้ปรึกษากับ Claude Code เพื่อจัดระเบียบ RAG ส่วนตัวของฉัน (เซิร์ฟเวอร์ ChromaDB + Ollama + MCP)

“คุณสามารถเพิ่มประสิทธิภาพ RAG ได้หรือไม่ มีพื้นที่ส่วนกลางสำหรับแต่ละโครงการใช่ไหม”

เป็นคำถามที่ฉันถามด้วยท่าทีสบายๆ หลังจากผ่านไปประมาณ 30 นาที ก็มีข้อเสนอแนะกลับมาหาฉันว่า “คุณควรแก้ไขปัญหานี้” และฉันก็วางแผนที่จะนำไปใช้และเข้านอน

ด้วยเหตุนี้ ฉันจึงได้สนทนาวิภาษวิธีกับคลอดด์จนถึงตี 2** ฉันลงเอยด้วยการแก้ไข AI ห้าครั้ง และ AI ก็เขียนข้อเสนอการออกแบบใหม่เพื่อการสังเคราะห์ห้าครั้ง

ก่อนที่ฉันจะรู้ การอภิปรายได้ขยายจาก การเพิ่มประสิทธิภาพ RAG ส่วนบุคคล ​​เป็น “การมี AI เป็นคู่ของคุณหมายความว่าอย่างไร” ซึ่งเป็นขอบเขตระหว่างวิทยาศาสตร์ความรู้ความเข้าใจ ทฤษฎีการดึงข้อมูล และระบบการแนะนำ

บทความนี้เป็นบันทึกการสนทนาในคืนนั้นและ หลักการออกแบบ RAG 5 ปี ที่ดึงมาจากบทความนี้

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

---

องก์ที่ 1: ภาพลวงตาว่า “ควรกลั่นให้สะอาด”

ข้อเสนอแรกของโคลดยอดเยี่ยมมาก> “มาออกแบบใหม่ให้เป็นโครงสร้าง 4 ชั้นกันดีกว่า ชั้นการเปิดใช้งาน ชั้นการดึงข้อมูล ชั้นการจัดเก็บ และชั้นการกลืนกิน พื้นที่จัดเก็บแบ่งออกเป็น 3 ชั้น และชั้นที่ 1 จะเก็บเฉพาะทรัพย์สินนิรันดร์ที่สะอาดเท่านั้น ชั้นที่ 2 อยู่ในระหว่างดำเนินการ และชั้นที่ 3 เป็นบัฟเฟอร์วงแหวนหน่วยความจำระยะสั้น ไปป์ไลน์การกลั่นเลื่อนจากชั้นที่ 3 ไปเป็นชั้นที่ 1…”

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

แต่มีบางอย่างไม่ถูกต้องสำหรับฉัน ฉันจึงถามอีกครั้ง

“การออกแบบในปัจจุบันไม่ดีเลย”

โคลดเปลี่ยนคำตอบของเขาโดยสิ้นเชิงหลังจากผ่านไป 3 วินาที (เวลาประสบการณ์ LLM)

“ขออภัย ฉันวิพากษ์วิจารณ์การสนทนานี้มากเกินไป การออกแบบในปัจจุบัน โดยพื้นฐานแล้วดี”

และ AI เองก็สารภาพกับดักสามอย่างที่เขาตกเข้าไป

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

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

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

การแลกเปลี่ยนครั้งนี้ทำให้ฉันได้ตระหนักถึงสิ่งแรก:

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

---

องก์ที่ 2: ข้อผิดพลาดร้ายแรงของศรัทธาที่กลั่นกรอง

ฉันคิดว่ามันคงจะเพียงพอแล้วที่จะพูดว่า “การออกแบบในปัจจุบันโดยพื้นฐานแล้วดี” แต่กลับกลายเป็นเรื่องราวที่ลึกซึ้งกว่านั้นมาก

RAG ของฉันได้รับการออกแบบมาเพื่อ กลั่นบันทึกดิบในภายหลัง สคริปต์นำเข้าอัตโนมัติจะทำงานทุก ๆ 30 นาที ป้อนบันทึกการสนทนา Copilot ไปที่ ChromaDB และ distill_v2 จัดประเภทและเลื่อนระดับเป็น lesson / idea / knowledge / profile / conclusion ด้วย gpt-4o-mini ของ GitHub Models

นี่เป็นการออกแบบโดยตั้งใจ: “อย่าหยุดทำงาน ทิ้งวัตถุดิบแล้วจัดโครงสร้างในภายหลัง”

แต่ในตอนแรกโคลดเขียนว่า:> “ไม่ควรป้อนบันทึกดิบจำนวนมาก แนวคิดที่เข้ามาในใจก่อนการกลั่นควรแยกออกก่อนที่จะนำเสนอ”

ฉันแก้ไขมันแล้ว

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

Claude ขอโทษอีกครั้งและยอมรับว่าทั้ง Tier 3 (ดิบ) และ Tier 1 (กลั่น) ล้วนมีคุณค่า อย่างไรก็ตาม ความคิดเรื่อง “ห้องนิรภัยที่สวยงาม” ยังคงอยู่ในใจของโคลด

ดังนั้นฉันจึงมีการสนทนาเชิงลึกมากขึ้น

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

นี่ไม่ใช่การปฏิเสธ แต่เป็น การยืนยัน เราถาม AI ว่า “คุณเข้าใจจริงๆ หรือไม่ว่า vector DB ที่คุณใช้งานอยู่นั้นใช้ทำอะไร”

การตอบสนองของ Claude เป็นการเขียนพื้นฐานการออกแบบใหม่

“นั่นเป็นความจริงอย่างยิ่ง ‘ศรัทธาในการกลั่นกรอง’ ของฉันเป็นแบบอย่างของสมองที่ผิด”

จากนั้นเขาก็ยอมรับว่าเขาได้เสนอการออกแบบที่จะทำให้ AI เป็น “องค์กรที่เข้มงวดซึ่งทำการตัดสินใจตามชั้นของจิตสำนึกเท่านั้น”

AI ที่ตัดสินใจโดยอาศัยภูมิปัญญาที่กลั่นกรองและชัดเจนเพียงอย่างเดียว ก็ไม่แตกต่างจากระบบผู้เชี่ยวชาญที่อิงกฎเกณฑ์ในช่วงปี 1990 พื้นที่เวกเตอร์ของ ChromaDB ใช้การประมาณค่าของการเรียกคืนแบบเชื่อมโยงโดยธรรมชาติผ่านความคล้ายคลึงกันทางความหมาย ซึ่งสอดคล้องกับชั้นหน่วยความจำโดยนัยของสมอง การมีข้อมูลดิบและซับซ้อนจำนวนมาก “อดีตที่คล้ายกับสิ่งนี้” จะปรากฏขึ้นสำหรับข้อความค้นหาใหม่ นั่นคือธรรมชาติที่แท้จริงของสัญชาตญาณ

การบรรยายบทเรียนที่กลั่นกรองออกมาเพียงอย่างเดียวไม่ได้สร้างสัญชาตญาณ

นี่คือสิ่งที่สองที่ฉันสังเกตเห็น:

**การมุ่งเป้าไปที่ “ความสะอาด” ของข้อมูลคือการตัดสินใจด้านการออกแบบที่ทำให้ AI เสื่อมถอยลงในกลไกกฎที่เข้มงวด ความซับซ้อนของข้อมูลดิบคือสิ่งที่ทำให้ vector DB เป็น “คู่หู” **

---

องก์ที่ 3: Google Maps พาฉันไปรอบๆ บริเวณฐานภูเขาไฟฟูจิ

ขณะที่การอภิปรายเกี่ยวกับการออกแบบดูเหมือนจะเคลื่อนไปสู่ความเป็นนามธรรม ฉันก็ยกตัวอย่างที่เป็นรูปธรรมขึ้นมา

ประมาณสี่ปีที่แล้ว มีความแตกต่างที่ชัดเจนระหว่างการนำทางของ Google Maps และการนำทางในรถของคุณ

เมื่อขับรถไปตามชนบท Google Maps มักจะเป็นเพียงสิ่งเดียวที่จะนำฉันไปสู่ทางลัด เช่น ถนนในป่าหรือเส้นทางเดินชมสัตว์ที่คนในพื้นที่เท่านั้นที่พาฉันไปได้ ระบบเดิมของรถจะไม่เลือกเส้นทางทำไมมีแต่ Google ที่รู้เรื่องนี้ อาจเป็นเพราะรวบรวมข้อมูลตำแหน่งจากสมาร์ทโฟน Android ในบรรดาเส้นทางที่ใช้โดย อาคารผู้โดยสารซึ่งเคลื่อนที่ด้วยความเร็ว 20 กม./ชม. หรือสูงกว่า จากจุด A ไปยังจุด B นั้น เส้นทางส่วนใหญ่ ถูกนำมาใช้ จากนั้นทางลัดที่คนในพื้นที่ใช้เป็นประจำทุกวันจะปรากฏบนบริการแผนที่แม้ว่าจะไม่มีใครเข้าไปก็ตาม

นี่คือข้อมูลอัจฉริยะที่เกิดขึ้นจากการรวบรวมทางสถิติของการติดตาม GPS แบบดิบ

เดิมที Claude เขียนว่า:

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

นี่คือจุดที่ฉันทำการแก้ไขครั้งที่สาม

“การถูกพาไปถนนป่า/เส้นทางชมสัตว์ไม่ใช่อุบัติเหตุ ถ้าไม่บอกฉัน ฉันจะไม่ไปที่นั่น ไม่เคยรู้ ฉันคิดว่านั่นเป็นเพราะที่นั่นรถสัญจรน้อยมาก มันอยู่ใกล้ตีนภูเขาไฟฟูจิ เป็นข้อมูลที่มีความหมายมาก”

นี่เป็นการแก้ไขสำหรับ Claude ที่พลิกโฉมการออกแบบไปอีกขั้นหนึ่ง

**สิ่งที่ถูกมองว่าเป็น “เสียงรบกวน” แท้จริงแล้วเป็นโอกาสครั้งหนึ่งในชีวิตสำหรับการค้นพบ **

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

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

สิ่งที่สามที่ควรสังเกตมีดังนี้:

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

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

---

องก์ที่ 4: เสียงและสัญญาณขึ้นอยู่กับผู้สังเกตการณ์

ที่นี่โคลดเหวี่ยงไปสู่จุดสูงสุดอีกครั้ง

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

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

ประโยคสุดท้ายประกอบด้วยการยั่วยุอันต่ำต้อยของฉัน “Claude ซึ่งเป็น AI น่าจะรู้เรื่องนี้ดีที่สุด” คือประเด็น

ทำไม

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

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

อย่างไรก็ตาม เมื่อพูดถึงการออกแบบ RAG ด้วยเหตุผลบางอย่าง Claude ก็ยังคงเสนอข้อเสนอการออกแบบที่ขัดแย้งกับหลักการทำงานของเขา เช่น “มาจัดหมวดหมู่แบบตายตัว ณ จุดจัดเก็บกันดีกว่า”

คำตอบของโคลดเป็นการสังเกตตนเองที่เจาะลึกที่สุดที่ฉันเคยเห็นในคืนนี้

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

สิ่งที่สี่ที่ควรสังเกตมีดังนี้:

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

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

---

องก์ที่ 5: แกนหลักของการออกแบบที่มีอายุการใช้งาน 5 ปี

หลังจากแก้ไขห้าครั้ง ในที่สุดเราก็มาถึงการสังเคราะห์

เมื่อคุณเขียนมันลงไป มันง่ายมาก

หลักการที่ 1 : Capture-First (อย่าทิ้งวัตถุดิบดิบ)

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

หลักการที่ 2: การกลั่นไม่ใช่การเติมหรือทดแทนเลื่อนระดับ raw ให้เป็นแบบมีโครงสร้าง lesson / idea / knowledge ฯลฯ ด้วย LLM (เช่น gpt-4o-mini)

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

หลักการที่ 3: Activation Layer (การแสดงออกของความรู้สึกของคู่ค้า)

ความแตกต่างที่สำคัญระหว่างเครื่องมือค้นหาและการแสดงร่วมคือ ดันหรือดึง

เครื่องมือค้นหาจะตอบเมื่อถูกถาม (ดึง) เพื่อนของคุณจะให้สิ่งที่คุณต้องการโดยไม่ต้องถูกถาม (ผลักดัน)

โดยเฉพาะโปรไฟล์ผู้ใช้ + บทเรียนสำคัญ + คำถามที่ยังไม่ได้รับการแก้ไขจะถูกฉีดโดยอัตโนมัติเมื่อเริ่มเซสชันไคลเอนต์ AI (Claude Code / Copilot) / ทุกเทิร์น Claude Code ใช้กลไกที่ส่งคืน additionalContext พร้อมด้วย UserPromptSubmit hook และ Copilot ใช้กลไกที่วางไฟล์ไว้ในโฟลเดอร์เครื่องมือหน่วยความจำ

ตอนนี้ AI จะเริ่มทุกการสนทนาในสถานะ “รู้จักคุณ”

หลักการที่ 4: การอยู่ร่วมกันหลายไคลเอนต์ (แนวคิดการออกแบบได้รับการสื่อสารในรูปแบบเอกสาร ไม่ใช่ API)

RAG ของฉันเขียนจากทั้ง Copilot และ Claude Code แม้ว่าคุณจะลบพารามิเตอร์ project ที่ระดับ MCP API หากไคลเอนต์ทั้งสองไม่ได้ใช้ปรัชญาการออกแบบเดียวกัน (บทเรียนมีโครงสร้าง ลำดับความสำคัญ=สูง ได้รับการคัดเลือกอย่างระมัดระวัง ฯลฯ) ฝ่ายหนึ่งจะยังคงเขียนด้วยปรัชญาเก่าด้วยความตั้งใจดี และ RAG จะถูกปนเปื้อน

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

หลักการที่ 5: ยอมรับการพึ่งพาผู้สังเกตการณ์

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

---

“4 สิ่งที่ไม่ควรทำ” (ฉันทำหมดในคืนเดียว)

โดยสรุป มีกับดักสี่ประการที่ควรหลีกเลี่ยงเมื่อออกแบบ RAG ด้วย AI

กับดัก 1: สร้างเพียงห้องใต้ดินที่สวยงามเท่านั้น

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

กับดัก 2: ทิ้งวัตถุดิบแม้ว่าเราจะแสดงรายการเฉพาะบทเรียนที่กลั่นกรองแล้ว ความคล้ายคลึงกับสถานการณ์ใหม่จะไม่เกิดขึ้น

มันทำลาย raison d’être ของ vector DB โดยสิ้นเชิง (การเรียกคืนแบบเชื่อมโยงผ่านการค้นหาพื้นที่ใกล้เคียง)

กับดัก 3: แก้ไขผู้สังเกตการณ์

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

กับดักที่ 4: การแบ่งแยกอุดมการณ์ระหว่างลูกค้า

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

---

วิธีขัดเกลาการออกแบบของคุณด้วย AI

สุดท้ายนี้ ฉันอยากจะเขียนเคล็ดลับบางประการในการดำเนินการตรวจสอบการออกแบบโดยร่วมมือกับ AI ซึ่งฉันได้รวบรวมมาจากประสบการณ์ของฉันในคืนนั้น

เคล็ดลับที่ 1: เมื่อ AI มาพร้อมกับ “วิธีแก้ปัญหาที่ดีที่สุด” ก่อนอื่นให้สงสัยก่อน

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

เคล็ดลับ 2: สอน AI “ทำไมฉันถึงทำแบบนี้”

AI มีแนวโน้มที่จะตัดสินใจก่อนที่จะฟังเหตุผล การอธิบายว่า เพื่อให้เราไม่หยุดทำงาน'' หรือ นี่เป็นวิธีแก้ปัญหาจากข้อผิดพลาดในอดีต” จะทำให้ AI ปฏิบัติต่อการออกแบบของคุณด้วยความเคารพ

เคล็ดลับ 3: เขย่าวิภาษวิธี

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

เคล็ดลับ 4: เชื่อสัญชาตญาณของคุณ

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

เคล็ดลับ 5: กระตุ้นการสังเกตตนเองจาก AI

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

เคล็ดลับ 6: บันทึกการค้นพบที่สำคัญทันที

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

---## บทสรุป: จดหมายถึงตัวเองในรอบ 5 ปี

ฉันไม่รู้ว่าในอีก 5 ปีข้างหน้าจะมีชื่อเฉพาะเจาะจงว่าอะไร ChromaDB อาจเพิ่มความแข็งแกร่งให้กับตำแหน่งของตนในฐานะศูนย์กลางของฐานข้อมูลเวกเตอร์ Ollama อาจถูกแทนที่ด้วยรันไทม์ LLM อื่น อาจเป็นไปได้ว่ามีการสร้างกลไกอื่นที่ไม่ใช่ hook UserPromptSubmit

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

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

และเหนือสิ่งอื่นใด

• เลือกดีไซน์ที่แสดงให้เห็นบริเวณฐานภูเขาไฟฟูจิ

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

---

ข้อมูลเพิ่มเติม: กองเทคโนโลยี

เพื่อเป็นข้อมูลอ้างอิง เราได้แสดงรายการสแต็กการใช้งาน RAG ที่กล่าวถึงในบทความนี้

เลเยอร์	เทคโนโลยี
เวกเตอร์ DB	ChromaDB (การคงอยู่ในท้องถิ่น)
การฝัง	nomic-embed-text (ผ่าน Ollama, 768 มิติ)
การกลั่น LLM	gpt-4o-mini (GitHub รุ่น API)
เซิร์ฟเวอร์ MCP	Python + FastMCP (การขนส่ง stdio)
ส่งอัตโนมัติ	Windows Task Scheduler (ทุก ๆ 30 นาที)
การเปิดใช้งาน (Copilot)	การฉีดไฟล์ผ่านกลไกเครื่องมือหน่วยความจำ
การเปิดใช้งาน (รหัส Claude)	additionalContext JSON การส่งคืนของ UserPromptSubmit hook

บทความการใช้งานโดยละเอียดสามารถดูได้ที่ สารบัญซีรี่ส์

---

เกี่ยวกับบทความนี้นั่นเองบทความนี้เกิดจากการสนทนาข้ามคืนกับ Claude Code

โคลดเป็นผู้เขียนร่าง แต่เนื้อหาเป็นบทสนทนาระหว่างฉันกับโคลด และการแก้ไขของฉันเป็นแก่นของบทความ

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

ฉันอยากทำสิ่งเดียวกันอีกครั้งกับตัวเองใน 5 ปี และกับ AI ใน 5 ปี