LLM-First หรือ Code-First? ปัญญาประดิษฐ์ควรอยู่ที่ไหนใน AI การผลิต

วิธีตัดสินใจว่าโมเดลควรทำอะไร, โค้ดของคุณควรทำอะไร, และวิธีเชื่อมต่อทั้งสอง.

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

การเปลี่ยนแปลงนั้นได้แบ่งสาขาออกเป็นสองส่วน – LLM-First หรือ Code-First

ในสถาปัตยกรรม LLM-first โมเดลอยู่ในศูนย์กลางและตัดสินใจว่าจะทำอะไรต่อไป มันอ่านคำขอ, เลือกเครื่องมือ, ตัดสินใจลำดับการทำงาน, ตรวจสอบผลลัพธ์ระหว่างขั้นตอน, และเปลี่ยนเส้นทางเมื่อจำเป็น

ในสถาปัตยกรรม code-first ซอฟต์แวร์/โค้ดยังคงเป็นผู้ควบคุมการจัดลำดับ, กฎธุรกิจ, การตรวจสอบ, สิทธิ์, และการดำเนินการ LLM ที่นี่ทำหน้าที่คล้ายผู้เชี่ยวชาญที่โค้ดเรียกใช้เมื่อจำเป็นต้องเข้าใจหรือสร้างภาษา

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

ทำไม LLM-First ถึงน่าสนใจ

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

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

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

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

Anthropic’s คำแนะนำการสร้าง AI Agents ที่มีประสิทธิภาพ คำแนะนำทำให้เกิดความแตกต่างที่ฉันกลับมาพิจารณาอยู่เสมอ. ในเวิร์กโฟลว์โมเดลและเครื่องมือทำตามเส้นทางที่โค้ดของคุณกำหนด. ในเอเจนต์, LLM จะกำหนดกระบวนการของตนเองและตัดสินใจว่าจะใช้เครื่องมืออย่างไร คำแนะนำเดียวกันแนะนำให้เริ่มต้นด้วยสถาปัตยกรรมที่ง่ายที่สุดที่แก้ปัญหา, แทนที่จะเพิ่มความซับซ้อนแบบ agentic อย่างรีเฟล็กซ์ ฉันอยากขีดเส้นใต้คำแนะนำนั้นสองครั้ง.

ขีดจำกัดของ “ให้โมเดลตัดสินใจ”

โมเดลสามารถให้เหตุผลเกี่ยวกับสิ่งที่ควรเกิดขึ้นได้ การให้เหตุผลไม่เท่ากับการบังคับใช้กฎ

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

อาจไม่ใช่ งานเหล่านี้เป็นเชิงกำหนด, ทดสอบได้, ตรวจสอบได้, และบังคับใช้ได้, และนั่นคือสิ่งที่ซอฟต์แวร์แบบดั้งเดิมทำได้ดี ความเสี่ยงเพิ่มขึ้นเมื่อโมเดลเข้าถึงเครื่องมือ. OWASP’s คำแนะนำด้านความปลอดภัย AI สร้างสรรค์ระบุการควบคุมที่เกินขอบเขตเป็นความเสี่ยงสำคัญ: การให้ระบบที่ใช้ LLM มีฟังก์ชัน, สิทธิ์, หรืออำนาจอิสระมากกว่างานที่ต้องการ การผลิตผลลัพธ์ของโมเดลที่แปลกหรือถูกดัดแปลงเป็นเรื่องหนึ่งเมื่อมันสร้างข้อความ แต่เป็นเรื่องที่ใหญ่กว่ามากเมื่อโมเดลสามารถกระทำในโลกจริง

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

Code-First ยังมีความสำคัญ

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

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

สิ่งนี้สอดคล้องกับแนวคิดการกำกับดูแลที่กว้างขึ้น. NIST AI Risk Management Frameworkขอให้องค์กรจัดการความเสี่ยงของ AI ทั่วทั้งการออกแบบ, การพัฒนา, การปรับใช้, และการใช้งาน. ส่วนคู่มือ Generative AI Profileเพิ่มว่า ระบบสร้างสรรค์อาจต้องการการตรวจสอบเพิ่มเติม, เอกสาร, การทบทวน, และการควบคุม, ขึ้นอยู่กับระดับความเสี่ยงที่เกี่ยวข้อง.

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

อะไรควรเกิดขึ้น?

และ

อะไรที่ได้รับอนุญาตให้เกิดขึ้น?

LLM มักจะช่วยในส่วนแรกได้ดี. ระบบเชิงกำหนดควรเป็นผู้รับผิดชอบส่วนที่สองโดยทั่วไป.

รูปแบบไฮบริด: ให้เหตุผลแบบความน่าจะเป็น, ดำเนินการแบบเชิงกำหนด

สำหรับแอปพลิเคชันระดับองค์กรส่วนใหญ่ คำตอบเชิงปฏิบัติคือการผสมผสาน. LLM ทำหน้าที่เป็นชั้นการตีความและให้เหตุผล. เซอร์วิสเชิงกำหนดทำหน้าที่เป็นชั้นการดำเนินการและบังคับใช้.

ตัวอย่างหนึ่ง. สมมติว่าผู้ช่วย AI ช่วยนักพัฒนาสร้างสภาพแวดล้อมการทดสอบ API ชั่วคราว, และนักพัฒนาพิมพ์ว่า: “ให้ฉัน sandbox สำหรับ workflow การรับลูกค้าใหม่”

LLM สามารถตีความข้อความนั้น, ค้นหา workflow ที่น่าจะหมายถึง, อ่านเอกสาร, และแนะนำ API ที่อาจเกี่ยวข้อง. แต่การสร้างสภาพแวดล้อมจริงไม่ควรพึ่งพาข้อความที่สร้างแบบอิสระ. โค้ดสามารถยืนยันว่า API ที่ร้องขอมีอยู่, ตรวจสอบสัญญา, ตรวจสอบการอนุญาต, บังคับใช้ขีดจำกัดทรัพยากร, สร้างการกำหนดค่าที่ได้รับการอนุมัติ, และดำเนินการปรับใช้.

การแบ่งโดยประมาณมีลักษณะดังนี้:

• LLM: เข้าใจ, ให้เหตุผล, จำแนก, เสนอ, สรุป.
• โค้ด: ตรวจสอบ, ให้สิทธิ์, คำนวณ, เก็บรักษา, บังคับใช้, ดำเนินการ.

แต่ละฝ่ายทำงานในสิ่งที่ตนเก่งที่สุด, และไม่มีฝ่ายใดถูกบังคับให้ทำตามจุดแข็งของอีกฝ่าย.

ขอบเขตมีความสำคัญยิ่งขึ้นเมื่อเอเจนต์มีพลังมากขึ้น

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

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

การอนุมัติจากมนุษย์ยังสามารถฝังไว้ในกระบวนการทำงานเองได้แทนที่จะเป็นเครือข่ายความปลอดภัยแบบไม่เป็นทางการ. Microsoft’s agent framework documentation, ตัวอย่างเช่น, รองรับการเรียกใช้เครื่องมือที่หยุดชั่วคราวจนกว่าบุคคลจะอนุมัติการดำเนินการที่ร้องขออย่างชัดเจน.

หลักการง่ายๆ: ยิ่งผลของการกระทำมีความสำคัญสูง, การควบคุมเชิงกำหนดที่รอบด้านควรยิ่งเข้มแข็ง.

ห้าคำถามที่ควรถามก่อนมอบงานให้ LLM

เมื่อฉันกำลังตัดสินใจว่าคอมโพเนนต์ควรเป็น LLM‑first หรือ code‑first, ฉันจะพิจารณาตามรายการต่อไปนี้:

1. งานนี้มีคำตอบที่ถูกต้องอย่างชัดเจนหรือไม่? หากใช่, ควรโน้มไปทางโค้ดเชิงกำหนด. การคำนวณภาษี, การกำหนดสิทธิ์, และการตรวจสอบสคีม่าไม่ควรเปลี่ยนแปลงเพราะโมเดลอ่านแตกต่างกันในวันนี้.
2. งานนี้เกี่ยวข้องกับภาษาที่คลุมเครือหรือข้อมูลที่ไม่มีโครงสร้างหรือไม่? หากใช่, LLM อาจให้คุณค่าที่แท้จริง.
3. จะเกิดอะไรขึ้นหากโมเดลทำผิดพลาด? สถาปัตยกรรมที่เหมาะสมสำหรับสรุปการประชุมแตกต่างอย่างมากจากสถาปัตยกรรมที่เหมาะสมสำหรับการเริ่มต้นการชำระเงิน.
4. ผลลัพธ์สามารถตรวจสอบได้อย่างอิสระหรือไม่? แผนที่สร้างโดย LLM จะปลอดภัยมากขึ้นเมื่อกฎเชิงกำหนดสามารถตรวจสอบการกระทำที่ได้ก่อนที่จะดำเนินการ.
5. งานนี้จำเป็นต้องใช้เอเจนต์จริงหรือ? หากคุณรู้ขั้นตอนแล้ว, กระบวนการทำงานปกติที่มีการเรียก LLM บางส่วนมักจะง่ายกว่า, ราคาถูกกว่า, ทดสอบง่ายกว่า, และดำเนินการง่ายกว่า.

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

ความเชื่อถือได้เป็นคุณสมบัติของสถาปัตยกรรม, ไม่ใช่พรอมต์

หลายทีมเริ่มต้นด้วยการพยายามปรับปรุงความเชื่อถือได้โดยพึ่งพาการออกแบบพรอมต์เป็นหลัก. พรอมต์มีความสำคัญ, แต่ไม่สามารถรับภาระทั้งหมดได้.

ระบบการผลิตควรสันนิษฐานว่าผลลัพธ์ของโมเดลบางครั้งอาจไม่สมบูรณ์ มีรูปแบบผิดพลาด ไม่คาดคิด หรือแค่ผิดพลาดเลย. OWASP Top 10 สำหรับแอปพลิเคชัน LLM ระบุความเสี่ยงเช่น การฉีดคำสั่ง และ การจัดการผลลัพธ์ที่ไม่เหมาะสม, ซึ่งย้ำนิสัยสำคัญ: ปฏิบัติต่อผลลัพธ์ของโมเดลเป็นข้อมูลที่ไม่เชื่อถือได้สำหรับระบบต่อไป, ไม่ใช่คำสั่งให้ทำงานโดยอัตโนมัติ.

สิ่งนั้นเปลี่ยนคำถามที่คุณถาม. แทนที่จะถาม “ฉันจะเขียนพรอมต์อย่างไรให้โมเดลปฏิบัติตามกฎเสมอ?”, ให้ถาม “ฉันจะออกแบบระบบอย่างไรให้กฎไม่สามารถถูกละเมิดได้แม้โมเดลทำผิดพลาด?”

นี่เป็นปัญหาสถาปัตยกรรมซอฟต์แวร์ ไม่ใช่ปัญหาการพรอมต์. พรอมต์สามารถบอกเอเจนต์ให้ไม่ทำการกระทำที่ไม่ได้รับอนุญาตได้. บริการการอนุญาตสามารถหยุดการกระทำนั้นได้จริง. สองการควบคุมนี้ไม่เท่าเทียมกัน.

เหนือการถกเถียง: ระบบแบบ Intent-First

เมื่อคิดถึงทั้งหมดนี้, ฉันเริ่มเชื่อว่าการถกเถียง LLM-first กับ code-first ชี้ไปสู่แนวคิดที่สาม: intent-first สถาปัตยกรรม.

ในระบบ intent-first, แอปพลิเคชันเริ่มต้นด้วยการทำความเข้าใจว่าผู้ใช้พยายามทำอะไร. นั่นคือจุดที่ LLM มีคุณค่าที่สุด, เพราะผู้คนมักไม่ระบุความต้องการอย่างแม่นยำ. จากนั้นระบบค่อยๆ แปลงความคลุมเครือเป็นการดำเนินการที่มีโครงสร้างและกำหนดได้.

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

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

สรุป

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

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

อนาคตของ AI ระดับองค์กรอาจไม่ใช่แค่ LLM-first หรือ code-first อย่างเดียว. มันคือการใช้ LLM เมื่อความไม่แน่นอนต้องการปัญญา, และใช้โค้ดเมื่อความแน่นอนต้องการการควบคุม.

ความแตกต่างนั้นอาจสำคัญกว่าการเลือกโมเดลที่คุณใช้.