ถอดรหัสคำศัพท์ใหม่ในโลก AI: จาก Loop Engineering ถึง Open Weights ที่นักพัฒนาต้องรู้

ท่ามกลางกระแสการพัฒนาซอฟต์แวร์ที่เปลี่ยนแปลงอย่างรวดเร็วในปัจจุบัน การมีคำศัพท์ใหม่ๆ เกี่ยวกับเครื่องมือ AI ปรากฏขึ้นมาตลอดเวลานั้นอาจสร้างความสับสนให้กับนักพัฒนาได้ไม่น้อย

คำศัพท์เหล่านี้มีทั้งที่ใช้อธิบายรูปแบบการทำงานที่มีประโยชน์จริง บางคำเป็นเพียงชื่อเรียกใหม่ที่หรูหรากว่าเดิม และบางคำก็ยังอยู่ระหว่างการนิยามความหมายให้ชัดเจนในขณะที่เทคโนโลยีกำลังวิวัฒนาการ

ในรายการ GitHub Podcast ตอนล่าสุด Marlene Mhangami, GPS และผม ได้ร่วมพูดคุยถึงชุดคำศัพท์ด้าน AI ที่นักพัฒนากำลังให้ความสนใจ ไม่ว่าจะเป็น loop engineering, Ralph loops, squads, harness engineering, hill climbing, forward deployed engineers ไปจนถึงความแตกต่างของ closed models, open weights และ open source models

หากคุณถนัดการอ่านมากกว่าการฟัง นี่คือคู่มือสรุปความหมาย ความสำคัญ และแนวคิดเบื้องหลังคำศัพท์เหล่านั้น

รับฟังตอนเต็มได้ที่ด้านล่างนี้! 👇

Loop engineering: ก้าวไปไกลกว่า one-shot prompts

Loop engineering คือแนวปฏิบัติในการออกแบบระบบที่เน้นการทำงานแบบทำซ้ำรอบตัวเอเจนต์ (agents) แทนที่จะเป็นการป้อนคำสั่ง (prompt) ด้วยตัวเองทีละงาน

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

Ralph loops: ญาติสายใช้กำลังของ loop engineering

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

แม้จะมีประโยชน์ในการย่อยงานขนาดใหญ่ผ่านวงจร plan-act-check ที่ทำซ้ำได้ แต่ข้อเสียคืออาจมีราคาแพงและไม่มีประสิทธิภาพ เนื่องจากทุกรอบการทำงานจะใช้ tokens และทรัพยากรประมวลผลเพิ่มขึ้นเรื่อยๆ ดังนั้นเป้าหมายของ Loop engineering คือการจัดโครงสร้างให้รูปแบบนี้ชัดเจนขึ้น เพื่อลดการสั่งให้เอเจนต์ "ลองอีกครั้ง" ซ้ำๆ โดยการเพิ่มทักษะ (skills), การตรวจสอบ (observability) และจุดตรวจสอบ (checkpoints) เข้าไปในระบบ

Squads, fleets, และ multi-agent workflows

หาก loops คือตัวกำหนดขั้นตอนการทำงาน (workflow) คำว่า "squads" และ "fleets" ก็คือวิธีการที่เอเจนต์หลายตัวจะเข้ามาทำงานร่วมกันในขั้นตอนนั้น

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

แนวคิดหลักคือการเน้นการทำงานแบบขนาน (parallelization) และความเชี่ยวชาญเฉพาะด้าน (specialization) แทนที่จะใช้เอเจนต์ตัวเดียวทำทุกอย่าง การแยกส่วนให้เอเจนต์ที่มีทักษะเฉพาะทางจัดการแต่ละกระบวนการจะช่วยให้งานมีประสิทธิภาพมากขึ้น

Harnesses: ระบบรอบตัวโมเดล

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

หากจะเปรียบเทียบให้เห็นภาพ Harness คือ "สายบังเหียน" ที่ใช้ควบคุมม้าซึ่งเปรียบเสมือนโมเดล เพื่อให้ม้าที่ทรงพลังสามารถทำงานได้อย่างปลอดภัยและตรงเป้าหมาย ตัวอย่างที่ชัดเจนคือ GitHub Copilot ที่ทำหน้าที่เป็น harness เชื่อมต่อโมเดลเข้ากับ codebase, editor และ terminal ของนักพัฒนา ดังนั้น "harness engineering" จึงหมายถึงการออกแบบและปรับปรุงระบบที่ควบคุมโมเดลเหล่านี้นั่นเอง

Hill climbing: การปรับปรุงเอเจนต์ด้วยผลตอบรับ

คำว่า "hill climbing" ใช้เพื่ออธิบายกระบวนการพัฒนาเอเจนต์และ harness ให้ดีขึ้นอย่างต่อเนื่องผ่านผลตอบรับ

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

Forward deployed engineer: บทบาทที่คุ้นเคยในมุมมอง AI

ตำแหน่ง forward-deployed engineer ไม่ใช่เรื่องใหม่ แต่การเข้ามาของ AI ทำให้บทบาทนี้ดูทันสมัยขึ้น โดยพื้นฐานแล้วคือวิศวกรที่ทำงานใกล้ชิดกับลูกค้า (คล้าย sales engineer) เพื่อนำโซลูชันทางเทคนิคไปปรับใช้ในสภาพแวดล้อมจริง

ในบริบทของ AI บุคคลในตำแหน่งนี้จะมีหน้าที่ช่วยทีมลูกค้าในการรวมเครื่องมือ AI, workflows และเอเจนต์ต่างๆ เข้ากับระบบเดิมที่มีอยู่เพื่อให้ใช้งานได้จริงอย่างราบรื่น

Closed models, open weights, และ open source models

การแบ่งปันโมเดลในปัจจุบันมีอยู่ 3 รูปแบบหลักที่ต้องแยกให้ชัดเจน ได้แก่ Closed models ซึ่งเข้าถึงได้ผ่าน API เท่านั้น โดยนักพัฒนาจะไม่เห็นน้ำหนักของโมเดล (weights) หรือข้อมูลที่ใช้ฝึก ต่อมาคือ Open weight models ที่เปิดให้ดาวน์โหลด weights มาใช้งานในเครื่องตัวเองได้ แต่อาจไม่ได้เปิดเผยชุดข้อมูลหรือวิธีฝึกทั้งหมด

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

คำศัพท์ต่างๆ กำลังพัฒนาอย่างต่อเนื่อง

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

นักพัฒนาควรให้ความสำคัญกับเรื่องพื้นฐาน เช่น workflow ทำซ้ำได้จริงไหม มีการตรวจสอบงานอย่างไร และมนุษย์ควรเข้ามาแทรกแซงในจุดใด ในยุคใหม่ของวิศวกรรมนี้ แนวทางปฏิบัติที่ดีที่สุด (best practices) ยังคงเป็นหัวใจสำคัญเสมอ

กดติดตาม GitHub Podcast เพื่อที่คุณจะไม่พลาดในทุกตอน!