การสังเกตการณ์ LLM: 6 บทเรียนจาก CTO ของ Datadog

บทเรียนที่ 1: AI ทำให้วิธีรีวิวโค้ดแบบเดิมใช้ไม่ได้

เริ่มจากแรงกดดันที่ทำให้ทุกอย่างเคลื่อนตัว: มีโค้ดมากกว่าที่ใครจะอ่านได้

Lê-Quôc พูดชัดว่าโมเดลเดิม ๆ คือมนุษย์อ่าน pull request ทีละบรรทัด จะอยู่ไม่ได้เมื่อเจอกับการพัฒนาที่มี AI ช่วย ความกังวลที่เขาได้ยินทั่วอุตสาหกรรมคือการรีวิวกำลังเป็นไปไม่ได้ เพราะมีสิ่งที่เกิดขึ้นมากเกินกว่าจะตามทันด้วยการอ่าน PR

คำตอบของเขาไม่ใช่ให้คนอ่านให้เร็วขึ้น แต่ย้ายเวทีรีวิวไปที่อื่น

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

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

บทเรียนที่ 2: สภาพแวดล้อมจริงคือบททดสอบเดียวที่นับ

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

ทุกรีลีสตั้งอยู่บนสมมติฐานที่ตรวจล่วงหน้าได้ไม่หมด ทั้งรูปร่างของข้อมูลและพฤติกรรมผู้ใช้ เมื่อสมมติฐานเหล่านั้นเจอทราฟฟิกจริงมากพอ เคสที่พบไม่บ่อยจะเลิกหายาก กลายเป็นความหน่วงและความผิดพลาดในชีวิตประจำวันจาก data และ model drift

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

ดังนั้นคุณจะเลิกพยายามพิสูจน์ความถูกต้องของระบบก่อนปล่อย แทนที่จะทำ คุณจะ

• เขียนการประเมินสำหรับพฤติกรรมที่ต้องการ
• มอนิเตอร์ในสภาพแวดล้อมจริง
• มีปุ่มหยุดสำหรับการปล่อยที่เริ่มแย่ลง

คำถามไม่ใช่ว่ามันผ่านหรือไม่ แต่คือปัญหานั้นเป็นครั้งเดียวจบหรือสัญญาณของแนวโน้ม

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

บทเรียนที่ 3: ให้เอเจนต์รับงานน่าเบื่อแทน

ข้อเสนอของ Lê-Quôc สำหรับ เอเจนต์ ไม่ใช่ว่าจะมาแทนวิศวกร แต่คือมารับส่วนงานที่ทำให้คนล้า

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

ประเด็นลึกกว่าคือความล้า การปล่อยระบบแบบ on-call คือการตื่นตัวฉับพลันตามด้วยชั่วโมงแห่งความว่างซ้ำ ๆ จนวิจารณญาณเริ่มพร่าเลือน

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

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

บทเรียนที่ 4: แยกงานออกเป็นสองลูป

Lê-Quôc จัดงานด้านเอเจนต์ของ Datadog รอบสองลูป

ลูปการพัฒนา

วิศวกรส่วนใหญ่จะคุ้นกับลูปแรก:

1. เขียนโค้ด
2. ปล่อย
3. ดูว่าเวิร์กไหม
4. แก้
5. ทำซ้ำ

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

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

ลูปปฏิบัติการและความปลอดภัย

อีกลูปหนึ่งทำงานขนานกัน โดยทีมเดียวกันหรือทีมต่างหาก:

1. ตรวจจับ
2. สืบค้น
3. แก้ไข
4. ทำซ้ำ

นี่คือที่ที่ AI Guard ของ Datadog คัดกรองเหตุการณ์ความปลอดภัยและบล็อกการโจมตีได้เร็วกว่านักวิเคราะห์ที่ทำด้วยมือ เอเจนต์ยังจัดการงานปฏิบัติการรูทีนที่วิศวกรทำกันทุกวันแบบไม่ค่อยอยากทำ เช่น ปรับขนาด Kubernetes pod นั้น

ทั้งสองลูป Lê-Quôc ย้ำเรื่องลำดับการทำงาน Datadog ไม่เริ่มจาก "นี่คือ AI จะแก้ปัญหาอะไรได้บ้าง?" แต่เริ่มจากปัญหาที่ลูกค้าบ่นอยู่แล้ว มักเป็นเวอร์ชันของ "ไม่อยากทำงานซ้ำซากนี้" แล้วค่อยย้อนกลับมาดูว่าเอเจนต์น่าไว้วางใจพอหรือไม่

บทเรียนที่ 5: ควบคุมค่าใช้จ่าย AI

ต้นทุนคือข้อจำกัดที่อยู่เคียงข้างความปลอดภัย และการควบคุมค่าใช้จ่ายของ การทำโมเดลภาษาใหญ่ให้เดินงานจริง กำลังกลายเป็นวินัยเฉพาะ ทางออกของ Lê-Quôc ในงาน DASH คือ Agent Console ของ Datadog

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

รูปแบบเหล่านั้นกลายเป็นฮิวริสติกไม่ใช่กฎตายตัว: ใช้รุ่นแนวหน้ารุ่นล่าสุดอย่าง Claude Opus หรือ GPT สำหรับการวางแผน ใช้รุ่นราคาถูกอย่าง Claude Haiku สำหรับการสร้างการทดสอบ

หลักการที่อยู่ใต้สิ่งนี้คือใครเป็นเจ้าของการตัดสินใจ หากม้วนต้นทุนรวมเป็นตัวเลขเดียว จะได้สิ่งที่ Lê-Quôc เรียกว่า "แอคชันได้ต่ำมาก" คือทุกคนหยุดใช้จ่าย ซึ่งฆ่างานที่มีประโยชน์ หรือทุกคนใช้จ่ายต่อ ซึ่งธุรกิจรับไม่ไหว เขาจึงอยากวางข้อมูลไว้ตรงหน้านักพัฒนาและ SRE ที่เลือกโมเดลเอง

บทเรียนที่ 6: เรียนรู้วิธีการเรียนรู้

เมื่อถามว่าวิศวกรรุ่นใหม่ควรเรียนรู้อะไร Lê-Quôc ให้คำตอบที่ฟังดูเก่าแต่ไม่เก่า

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

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

• คำนี้หมายความว่าอะไร?
• จะวัดมันอย่างไร?
• คณิตศาสตร์เบื้องหลังคืออะไร?
• รู้ได้อย่างไรว่ามันทำงานดี?

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

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

ข้อคิดส่งท้าย

สารหลักของ Lê-Quôc คือ ลูปไม่เปลี่ยน แต่จังหวะเปลี่ยน ความต่างคือไม่มีมนุษย์คนไหนดูได้ละเอียดพอด้วยความเร็วที่ AI เคลื่อนที่อยู่ตอนนี้ ดังนั้นการเฝ้าดู และส่วนงานสร้างที่เพิ่มขึ้น จะย้ายไปอยู่กับเอเจนต์ที่ไม่เหนื่อยและไม่ตื่นตระหนก

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

ทักษะที่กรอบคิดนี้ขอจากวิศวกรจึงชัดเจน: อ่านระบบผ่านพฤติกรรมในโปรดักชัน ไม่ใช่แค่ผ่านซอร์สโค้ด หากอยากฝึกนิสัยนี้ เส้นทางทักษะ Machine Learning in Production ของเราคือจุดเริ่มต้นที่ดี