- ช่วงหลังมานี้ ในอุตสาหกรรมซอฟต์แวร์ แนวคิดที่เรียกว่า 'Software Factory' ได้รับความสนใจอย่างมาก เป็นกระบวนทัศน์ใหม่ที่ AI agent ซึ่งสามารถดำเนินงานหลายขั้นตอนด้วยตัวเองตามเป้าหมายที่กำหนด รับหน้าที่เขียนซอร์สโค้ดทั้งหมด ขณะที่นักพัฒนามุ่งเน้นไปที่การสร้างและยกระดับระบบหรือ 'โรงงาน' ที่ทำให้สามารถผลิตโค้ดนั้นได้อย่างเสถียร
- Dru Knox แห่ง Tessl บริษัทเครื่องมือพัฒนา AI ได้ตั้งชื่อระเบียบวินัยการพัฒนาแบบใหม่นี้ว่า Harness Engineering
- Harness หมายถึงเฟรมเวิร์กทั้งหมดที่ใช้ควบคุมและขับเคลื่อน AI agent เปรียบเหมือนอานหรือเครื่องเทียมม้าที่สวมให้ม้า และหัวใจของเฟรมเวิร์กนี้คือสามลูป (Loop, วงจรที่วนทำขั้นตอนเดิมซ้ำ)
- สิ่งที่วิดีโอพูดถึง: Software Factory คืออะไร และตัวชี้วัด 3 อย่างที่ใช้กำหนดมัน / เหตุผลที่ Tessl แบน interactive coding session ภายในบริษัท และสิ่งที่เกิดขึ้นหลังจากนั้น / สามชั้นคือ inner, outer, meta loop / เหตุใด Harness Engineering จึงยาก / วิธีที่ change review และ verifier ของ Tessl นำแนวคิดนี้ไปใช้จริง
- วิดีโอ: https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
เมื่อนำโครงสร้างเดียวกันนี้มาประยุกต์ใช้กับการผลิตความรู้
- Knowledge Factory คือระบบที่ AI agent เขียนหน้า wiki และมนุษย์ออกแบบและปฏิบัติการ 'ระบบกองบรรณาธิการ' ที่ทำให้ผลิตได้ต่อเนื่อง ผู้ปฏิบัติการไม่ได้เขียนบทความด้วยตนเอง แต่ดูแลแนวทางการเขียนและกลไกการตรวจสอบอัตโนมัติ
- โครงสร้างภายในโรงงานนำระบบบทบาท 5 อย่างของกองบรรณาธิการหนังสือพิมพ์มาเป็นต้นแบบ ได้แก่ นักข่าว คอลัมนิสต์ พิสูจน์อักษร เดสก์ และบรรณาธิการบริหาร
- จุดสำคัญคือ ทั้ง 5 บทบาทนี้ไม่ได้เป็น 'AI ที่ตัดสิน' ทั้งหมด 'พิสูจน์อักษร' ไม่ใช่ AI แต่เป็นโค้ด Python แบบอิงกฎ และ 'บรรณาธิการบริหาร' เป็นผู้ประสานงานที่กระจายงาน ตำแหน่งเดียวที่ AI ทำหน้าที่ประเมินและตัดสินอย่างอิสระคือ 'เดสก์'
- การออกแบบโรงงานอย่างมีประสิทธิภาพไม่ใช่การเพิ่มจำนวน agent แบบไม่ลืมหูลืมตา แต่คือการกำหนดให้ชัดว่าควรวางพื้นที่การตัดสินไว้ตรงไหน และตัดออกจากตรงไหน
สามแกนของความสุกงอม และความเชื่อมั่น
- ความสุกงอมของระบบวัดด้วย 3 แกน ได้แก่ autonomy (การทำหน้าให้เสร็จโดยไม่มีมนุษย์แทรกแซง), automation (ขอบเขตที่อนุญาตให้เผยแพร่โดยไม่ต้องให้มนุษย์ตรวจ), และ quality (ระดับของความรู้ที่ผลิตออกมา)
- แม้ autonomy จะสูง แต่หากผู้ปฏิบัติการยังกังวลจนต้องตรวจทุกหน้าทั้งหมด ระดับ automation ก็ยังถือว่าต่ำ องค์ประกอบสำคัญที่ใช้ปิดช่องว่างนี้ก็คือ 'ความเชื่อมั่น'
- เริ่มจากทำให้เกิด autonomy ก่อน จากนั้นขยายพื้นที่ automation เท่าที่มีความเชื่อมั่นสะสม และรักษาระดับคุณภาพให้คงที่ในกระบวนการนั้น กลไกที่ค้ำประกันความเชื่อมั่นนี้ก็คือ 'ลูป'
1. Inner Loop — การตรวจสอบตัวเองแบบเรียลไทม์
- Inner loop คือขั้นตอนตรวจสอบที่รวดเร็วและมีน้ำหนักเบา ซึ่ง agent รันอยู่เรื่อย ๆ ระหว่างเขียน ก่อนจะส่งฉบับร่าง ยิ่งลูปนี้ประณีตมากเท่าไร AI agent ก็ยิ่งแก้ข้อผิดพลาดได้เองโดยไม่ต้องอาศัยมนุษย์ และส่งผลให้ autonomy สูงขึ้น
- ระหว่างเขียน จะใช้เครื่องมือตรวจ Python (
tools/lint.py) เพื่อตรวจเฉพาะเอกสารที่ตัวเองสร้างขึ้น และหากข้อผิดพลาดเดิมเกิดซ้ำเกิน 2 ครั้ง จะส่งต่อไปยังขั้นถัดไปทันทีเพื่อรักษาความเร็วในการประมวลผล
2. Outer Loop — ด่านคู่ก่อนเผยแพร่
- ด่านแรกคือการพิสูจน์อักษร โค้ด Python จะทำ static check 10 ด้าน เช่น ลิงก์ การอ้างอิง โครงสร้างเอกสาร และความขัดแย้งของข้อมูล ตามกฎเชิงกำหนดตายตัว
- ด่านที่สองคือเดสก์ ประเมินเชิงคุณภาพจากมุมมองของผู้อ่านบุคคลที่สามใน 6 ด้าน เช่น อคติ ความหนาแน่นของข้อมูล ความอ่านง่าย และลำดับการนำเสนอ โดยไม่แก้ไขโดยตรง แต่คืนมาเป็นเพียงรายการสิ่งที่ต้องปรับปรุง
- สิ่งนี้เหมือนกับโครงสร้าง 2 ชั้นของ verifier (ด่านแรก) และ change review (ด่านที่สอง) ใน Software Factory
- ตรงนี้มีหลักการออกแบบที่สำคัญอย่างยิ่งข้อหนึ่ง เดสก์จะได้รับเฉพาะต้นฉบับที่เสร็จแล้วกับเกณฑ์ประเมินเท่านั้น โดยจะไม่ได้รับเจตนาในการเขียนของผู้เขียน เพราะเมื่อคนเขียนตรวจงานตัวเองในบริบทเดียวกัน การตัดสินมักผ่อนปรนเกินไป จึงปิดกั้นข้อมูลตั้งแต่ต้นเพื่อป้องกันอคตินี้
- ความแตกต่างที่แท้จริงของระบบนี้ไม่ใช่ว่ารัน agent กี่ตัว แต่คือการแยกบริบทแบบนี้เอง หากถูกปฏิเสธด้วยเหตุผลเดิมครบ 3 ครั้ง จะหยุดการดำเนินการอัตโนมัติและส่งต่อการตัดสินให้ผู้ปฏิบัติการที่เป็นมนุษย์
3. Meta Loop — กลไกการปรับปรุงตัวเอง
- ยึดหลักว่า "จะไม่ปล่อยให้เกิดความผิดพลาดเดิมซ้ำเป็นครั้งที่สอง ข้อผิดพลาดที่พบต้องถูกยกระดับเป็นกฎของระบบ"
- หากข้อบกพร่องเดิมยังเกิดซ้ำอย่างต่อเนื่อง ระบบจะเสนอร่างแก้ไขแนวทางการเขียนโดยอัตโนมัติ ร่างที่เสนอจะต้องผ่านทั้งการประเมินเปรียบเทียบแบบ blind โดยซ่อนว่าเนื้อหาใดเขียนด้วยกฎที่แก้ไขแล้ว และการทดสอบกับกรณีล้มเหลวใหม่ที่ไม่เคยใช้ในการตรวจสอบมาก่อน
- จะนำไปใช้กับระบบก็ต่อเมื่อคะแนนดีขึ้นจริงเท่านั้น และต้องได้รับ การอนุมัติขั้นสุดท้ายจากผู้ปฏิบัติการที่เป็นมนุษย์ เสมอ
- ประเด็นที่ถูกทักซ้ำ ๆ จะถูกยกระดับเป็น Python hook หรือกฎการพิสูจน์อักษร แล้วฝังให้เป็นโค้ดอย่างถาวร โดยย้ายพื้นที่การตัดสินเชิงคุณภาพไปสู่พื้นที่ตรวจสอบตามกฎ เพื่อช่วยให้เดสก์โฟกัสกับปัญหาระดับสูงได้อย่างต่อเนื่อง
4. Reground Loop — ลูปที่สี่ซึ่งจำเป็นเฉพาะกับความรู้
- โค้ดซอฟต์แวร์เมื่อ build และ deploy แล้ว มักคงสภาพเสถียรจนกว่าสเปกจะเปลี่ยน แต่ ทรัพย์สินความรู้จะค่อย ๆ ล้าสมัยเมื่อเวลาผ่านไป เพราะข้อเท็จจริงในโลกจริงเริ่มห่างออกจากเนื้อหาเดิม
- เพื่อแก้ปัญหานี้ จึงเพิ่มลูปที่สี่ชื่อ Reground (หมายถึงกลับไปยืนบนหลักฐานอีกครั้ง) โดยป้อนเอกสารที่เผยแพร่แล้วกลับเข้าไปเป็นอินพุตของโรงงานผลิตความรู้อีกครั้ง
- อัปเดต: เมื่อแหล่งข้อมูลต้นทางมีการเปลี่ยนแปลง คอลัมนิสต์จะนำหน้าที่เครื่องมือตรวจพบว่าล้าสมัยมาวิเคราะห์ใหม่และอัปเดต (ข่าวติดตามผล)
- ฟอลโลว์อัป: เมื่อในเอกสารมีประโยคที่ระบุว่า 'ต้องตรวจสอบเพิ่มเติมภายหลัง' หรือมีเงื่อนไขที่มีกรอบเวลา เมื่อถึงกำหนด เดสก์และผู้ปฏิบัติการจะตรวจสอบซ้ำ (การติดตามความคืบหน้า)
- แก้ไข: เมื่อพบความขัดแย้งของข้อมูลระหว่างหน้าต่าง ๆ ของเรา เดสก์จะกลับไปอ่านเอกสารทั้งชุดในระดับคลัสเตอร์ที่เผยแพร่แล้วอีกครั้ง เพื่อจับความไม่สอดคล้องที่มองไม่เห็นหากดูทีละหน้า (การรายงานแก้ไข)
Human-in-the-Loop
- สถานการณ์ยกเว้นที่ต้องใช้การอนุมัติจากมนุษย์ถูกนิยามและจัดการด้วยเช็กลิสต์ที่ชัดเจน แทนการพึ่งสัญชาตญาณ
- ปัจจุบันระบบทำงานในสภาวะที่เพิ่ม autonomy แต่จงใจจำกัด automation เอาไว้ กล่าวคือ agent สามารถเขียนหน้าได้เอง แต่การเผยแพร่ลง Wiki และการเปลี่ยนกฎการเขียนยังต้องได้รับการอนุมัติขั้นสุดท้ายจากมนุษย์
ข้อความเต็ม: https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/
ยังไม่มีความคิดเห็น