ผู้นำทางความคิด

ทำไมไพโลต์ AI ขององค์กรจึงติดค้างก่อนเข้าสู่การผลิต: ไม่ใช่เรื่องของโมเดล แต่เป็นเรื่องของฮาร์เนส

mm
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google

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

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

ช่องว่างที่ทุกคนกำลังวัด

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

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

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

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

รูปแบบ: การแก้ไขที่ตัดสินใจแทบจะไม่ใช่โมเดล

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

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

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

การยึดหลัก ไม่ใช่โมเดลที่ฉลาดกว่า คือสิ่งที่ทำให้เอเจนต์ปลอดภัยพอที่จะส่งออก

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

สิ่งที่ทำให้ระบบสามารถส่งออกได้คือฮาร์เนส: การออกแบบการดึงข้อมูลที่ดึงเฉพาะจากแหล่งที่มีการควบคุมและปลอดภัยสำหรับผู้เช่า การยึดหลักการตรวจสอบที่ยืนยันคำกล่าวที่สร้างขึ้นเทียบกับแหล่งที่มาเหล่านั้นก่อนที่จะถึงผู้ใช้ และขั้นตอนการตรวจสอบที่จะลบออกแทนที่จะยืนยันสิ่งที่ไม่ได้รับการสนับสนุน ผลลัพธ์คือการลดการหลอกลวงลง 80 ถึง 90% เมื่อเทียบกับฐาน LLM และความแม่นยำในการยึดหลักมากกว่า 95% ในขณะที่ยังคงความหน่วง P95 น้อยกว่า 2 วินาที เพื่อให้ชั้นความปลอดภัยไม่ทำให้ระบบรู้สึกช้า

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

การกำหนดเส้นทางโมเดล ไม่ใช่การเลือกโมเดล คือที่ที่ต้นทุน AI ถูกตัดสิน

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

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

ใน การย้ายที่เราทำจาก API LLM ของบุคคลที่สาม ไปยัง Amazon Bedrock ผลประโยชน์มาจากการออกแบบชั้นโมเดลใหม่ ไม่ใช่การเปลี่ยนโมเดล การกำหนดเส้นทางงานแต่ละงานไปยังระดับโมเดลที่เหมาะสม ร่วมกับการควบคุมต้นทุนและการกำกับดูแลของ Bedrock ที่เป็นเจ้าของ ทำให้ลดต้นทุนโครงสร้างพื้นฐาน AI ลง 42% และเพิ่มความเร็วในการสร้างเนื้อหาที่เป็นไปตามข้อกำหนด 60% โดยไม่ต้องสร้างแอปพลิเคชันใหม่

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

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

ทำไมสิ่งนี้จึงมองไม่เห็นในข้อมูลการสำรวจ

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

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

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

สิ่งนี้หมายถึงอะไรหากไพโลต์ของคุณติดค้าง

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

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

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

Akshat Agrawal เป็น GenAI Architect ที่ NeenOpal ซึ่งเป็นบริษัทที่ปรึกษาด้านข้อมูลและ AI และเป็นคู่ค้าด้านความสามารถของ AWS ในส่วนของ Generative & Agentic AI ที่สามารถให้บริการบน Microsoft Azure ได้ ตัวเลขการวางระบบที่อ้างอิงใน đây ได้มาจากกรณีศึกษาที่ NeenOpal เผยแพร่แล้ว