วิธีสร้างขีดความสามารถด้าน AI ให้ทีมวิศวกรรมโดยไม่ต้องเริ่มต้นใหม่ทั้งหมด

องค์กรต่าง ๆ เพิ่มขีดความสามารถในการส่งมอบ AI ให้ทีมวิศวกรรมซอฟต์แวร์ที่มีอยู่ โดยการฝังวิศวกร AI-native เข้าไปในทีมเดิม ปรับปรุง delivery pipeline ให้รองรับ workload ของ AI ให้ทันสมัย และดำเนินการถ่ายทอดขีดความสามารถอย่างเป็นระบบ แทนที่จะแทนที่ทีมหรือเริ่มต้นสร้างใหม่ทั้งหมด

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

การสร้างขีดความสามารถด้านวิศวกรรม AI ให้ทีมที่มีอยู่หมายความว่าอย่างไร?

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

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

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

เหตุใดการผสานรวมวิศวกรรม AI ส่วนใหญ่จึงหยุดชะงักหรือล้มเหลว?

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

รูปแบบที่สี่: องค์กรว่าจ้างที่ปรึกษา AI ที่จัดทำเอกสารกลยุทธ์และเดโม proof-of-concept แต่ไม่ได้สร้างระบบที่ใช้งานจริง ช่องว่างระหว่างเดโมที่ใช้งานได้กับฟีเจอร์ AI ระดับ production ที่มีการกำกับดูแลนั้นมีนัยสำคัญ ความหยุดชะงักส่วนใหญ่เกิดขึ้นในช่องว่างนั้นเอง

จะเพิ่มขีดความสามารถด้าน AI ให้ทีมวิศวกรรมซอฟต์แวร์โดยไม่ต้องสร้างใหม่ทั้งหมดได้อย่างไร?

แนวทางเชิงปฏิบัติประกอบด้วยสี่ขั้นตอน ซึ่งดำเนินการตามลำดับแทนที่จะทำพร้อมกัน

ประเมินบริบทการส่งมอบในปัจจุบัน ก่อนที่จะเริ่ม workstream ด้าน AI ให้ทำแผนผังว่าทีมที่มีอยู่กำลังสร้างอะไร ส่งมอบอย่างไร และฟีเจอร์ AI จะเชื่อมต่อกับระบบที่มีอยู่ตรงไหน สิ่งนี้ช่วยป้องกันปัญหาการผสานรวมที่มักเกิดขึ้นในช่วงท้ายของการส่งมอบ
ฝังวิศวกร AI-native เข้าไปใน sprint ที่มีอยู่ วิศวกร AI เข้าร่วมวงจรการส่งมอบที่มีอยู่ของทีมแทนที่จะดำเนิน workstream แยกต่างหาก พวกเขามีส่วนร่วมในการวางแผน sprint, standup ประจำวัน และการประชุม review ร่วมกับวิศวกรปัจจุบัน
ปรับปรุง delivery pipeline ให้ทันสมัยเพื่อรองรับ workload ของ AI ฟีเจอร์ AI ต้องการโครงสร้างพื้นฐานที่ delivery pipeline มาตรฐานส่วนใหญ่ไม่มีอยู่ในตัว ได้แก่ การจัดการเวอร์ชันโมเดล การจัดการ data pipeline การเฝ้าติดตาม inference endpoint และตัวกระตุ้นการฝึกใหม่ (retraining) สิ่งเหล่านี้จะถูกเพิ่มเข้าไปใน pipeline ที่มีอยู่แทนที่จะสร้างแยกต่างหาก
ดำเนินการถ่ายทอดขีดความสามารถอย่างเป็นระบบตลอดความร่วมมือ ทุก workstream ด้าน AI จะถูกบันทึกเป็นเอกสาร ทบทวนร่วมกับทีมภายใน และส่งมอบพร้อม runbook วิศวกรภายในจะถูกกำหนดให้เป็นคู่หูของวิศวกร AI เพื่อให้ความรู้ถูกถ่ายทอดระหว่างการส่งมอบ ไม่ใช่หลังจากนั้น

ทีมที่มีอยู่ต้องการทักษะด้านวิศวกรรม AI ใดบ้าง?

ทักษะที่จำเป็นขึ้นอยู่กับฟีเจอร์ AI ที่ทีมต้องส่งมอบ สามหมวดหมู่ครอบคลุมความต้องการส่วนใหญ่สำหรับบริษัทซอฟต์แวร์ในภูมิภาค APAC

ทักษะการผสานรวม machine learning จำเป็นเมื่อทีมกำลังเพิ่มฟีเจอร์เชิงพยากรณ์ ระบบแนะนำ หรือโมเดลจำแนกประเภทเข้าไปในผลิตภัณฑ์ที่มีอยู่ ทักษะเหล่านี้รวมถึงการประเมินโมเดล การผสานรวม API และการเฝ้าติดตามประสิทธิภาพของโมเดลในสภาพแวดล้อมจริง

ทักษะด้าน data engineering จำเป็นเมื่อฟีเจอร์ AI ขึ้นอยู่กับ data pipeline ที่ทีมปัจจุบันยังไม่ได้ดำเนินการ ทักษะเหล่านี้รวมถึงการออกแบบ ETL การกำกับดูแลคุณภาพข้อมูล และความน่าเชื่อถือของ pipeline

ทักษะด้านโครงสร้างพื้นฐาน AI จำเป็นเมื่อทีมนำโมเดลไปใช้งานในระดับขนาดใหญ่ ทักษะเหล่านี้รวมถึงการจัดการ container orchestration สำหรับการให้บริการโมเดล การเฝ้าติดตาม latency การบริหารต้นทุนสำหรับ inference และการออกแบบ failover

Gradion ฝังวิศวกรที่มีชุดทักษะที่เหมาะสมสำหรับแต่ละความร่วมมือ แทนที่จะจัดวางทีม AI แบบทั่วไปที่ครอบคลุมทุกด้านแต่มีความลึกน้อยกว่า

AI-native Engineering คืออะไร และเหตุใดจึงสำคัญสำหรับทีมในภูมิภาค APAC?

AI-native engineering หมายถึงแนวทางการส่งมอบที่ออกแบบขีดความสามารถด้าน AI เข้าไปในสถาปัตยกรรมของระบบตั้งแต่แรกเริ่ม แทนที่จะเพิ่มเข้ามาเป็นฟีเจอร์ภายหลัง วิศวกร AI-native จะประเมินการออกแบบระบบโดยคำนึงถึง workload ของ AI ได้แก่ การไหลของข้อมูล ความทนทานต่อ latency ความถี่ในการอัปเดตโมเดล และข้อกำหนดด้าน observability

สำหรับทีมในภูมิภาค APAC ความแตกต่างนี้มีความสำคัญ เพราะบริษัทซอฟต์แวร์ในภูมิภาคจำนวนมากกำลังอยู่ ณ จุดเปลี่ยนผ่าน พวกเขามีผลิตภัณฑ์และทีมส่งมอบที่จัดตั้งไว้แล้ว และกำลังเพิ่มฟีเจอร์ AI ภายใต้แรงกดดันด้านการแข่งขัน ทีมที่เพิ่มฟีเจอร์ AI โดยไม่มีหลักการออกแบบแบบ AI-native มักสะสม technical debt ที่จำกัดขอบเขตในการขยายขีดความสามารถด้าน AI ภายในผลิตภัณฑ์

แนวทาง AI-native engineering สร้างชั้น AI อย่างเป็นระเบียบ โดยใช้มาตรฐานการกำกับดูแลและความน่าเชื่อถือเดียวกันกับที่ใช้กับส่วนที่เหลือของระบบ

Gradion เพิ่มขีดความสามารถด้าน AI ให้ทีมวิศวกรรมอย่างไร?

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

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

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

คำถามที่พบบ่อย

ต้องใช้เวลานานเท่าใดในการเพิ่มขีดความสามารถด้าน AI ให้ทีมวิศวกรรมที่มีอยู่?

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

ความแตกต่างระหว่างที่ปรึกษา AI กับพันธมิตรด้านวิศวกรรม AI คืออะไร?

ที่ปรึกษา AI โดยทั่วไปส่งมอบกลยุทธ์ คำแนะนำ และงาน proof-of-concept ส่วนพันธมิตรด้านวิศวกรรม AI จะฝังตัวเข้ากับทีมส่งมอบและสร้างระบบที่ใช้งานจริง ความแตกต่างในทางปฏิบัติคือ งานของที่ปรึกษามักต้องการความพยายามด้านวิศวกรรมแยกต่างหากเพื่อไปสู่ระดับ production ในขณะที่งานของพันธมิตรด้านวิศวกรรมพร้อมใช้งานจริงตั้งแต่วันที่ส่งมอบ สำหรับบริษัทที่ต้องการฟีเจอร์ AI ที่ถูกส่งมอบและดูแลรักษาได้จริง ไม่ใช่แค่ถูกประเมิน โมเดลพันธมิตรด้านวิศวกรรมถูกออกแบบมาเพื่อสร้างผลลัพธ์ที่รวดเร็วและยั่งยืนกว่า Gradion ดำเนินงานในฐานะพันธมิตรด้านวิศวกรรม โดยมีวิศวกรระดับอาวุโสฝังตัวอยู่ในการส่งมอบ สร้างระบบระดับ production และถ่ายทอดขีดความสามารถให้ทีมภายใน

จะประเมินได้อย่างไรว่าพันธมิตรด้านวิศวกรรม AI เหมาะสมกับทีมของคุณหรือไม่?

ให้ประเมินพันธมิตรด้านวิศวกรรม AI จากสามเกณฑ์ ประการแรก พวกเขาฝังตัวเข้ากับวงจรการส่งมอบที่มีอยู่ของคุณ หรือดำเนิน workstream แยกต่างหาก? พันธมิตรที่ทำงานแยกต่างหากมักก่อให้เกิดปัญหาการส่งต่องาน ประการที่สอง พวกเขารวมการถ่ายทอดขีดความสามารถเป็นส่วนหนึ่งของโครงสร้างความร่วมมือหรือไม่ หรือเอกสารเป็นเพียงสิ่งที่ส่งมอบครั้งสุดท้าย? พันธมิตรที่ถ่ายทอดความรู้ตลอดกระบวนการส่งมอบจะสร้างผลลัพธ์ที่ยั่งยืนกว่า ประการที่สาม พวกเขามีประสบการณ์ที่พิสูจน์ได้ในการส่งมอบฟีเจอร์ AI สู่ระบบจริงในอุตสาหกรรมของคุณหรือบน technology stack ของคุณหรือไม่? ขอตัวอย่างสถาปัตยกรรมและความร่วมมืออ้างอิงภายใต้ข้อตกลง NDA ประเมินพันธมิตรจากหลักฐานการส่งมอบจริง ไม่ใช่จากระดับอาวุโสของทีมขาย

ทีมวิศวกรรม AI ที่ตั้งอยู่ในเวียดนามสามารถทำงานร่วมกับทีมผลิตภัณฑ์ที่ตั้งอยู่ในสิงคโปร์ได้อย่างมีประสิทธิภาพหรือไม่?

ได้ เวียดนามและสิงคโปร์มีช่วงเวลาทำงานที่ทับซ้อนกันมาก โดยชั่วโมงทำงานสอดคล้องกันเกือบตลอดวันทำงาน สิ่งนี้เอื้อให้สามารถเข้าร่วม sprint ceremony, การประชุมทบทวนการออกแบบ และการโทรเพื่อยกระดับปัญหาได้แบบเรียลไทม์โดยไม่มีความล่าช้าแบบ asynchronous ทีมวิศวกรรม AI ของ Gradion ดำเนินงานในรูปแบบนี้ในความร่วมมือที่กำลังดำเนินอยู่หลายโครงการ โครงสร้างความร่วมมือถูกออกแบบขึ้นโดยยึด standup ประจำวัน การทบทวนการส่งมอบรายสัปดาห์ และการสื่อสารโดยตรงผ่าน Slack และวิดีโอระหว่างวิศวกรทั้งสองฝ่าย ความต่างของเขตเวลาถูกจัดการในฐานะตัวแปรด้านการประสานงาน ไม่ใช่อุปสรรค

ทีมวิศวกรรมต้องมีโครงสร้างพื้นฐานใดบ้างก่อนเพิ่มขีดความสามารถด้าน AI?

ข้อกำหนดโครงสร้างพื้นฐานขั้นต่ำสำหรับการเพิ่มขีดความสามารถด้าน AI ให้ทีมวิศวกรรม ได้แก่ สภาพแวดล้อมการนำไปใช้งานแบบ containerized คลังข้อมูลที่มีโครงสร้างพร้อมการควบคุมการเข้าถึงที่กำหนดไว้ชัดเจน CI/CD pipeline ที่สามารถขยายให้ครอบคลุมการนำโมเดลไปใช้งาน และเครื่องมือเฝ้าติดตามที่สามารถติดตาม inference latency และคุณภาพผลลัพธ์ของโมเดล ทีมที่ขาดรากฐานเหล่านี้จำเป็นต้องแก้ไขก่อนหรือระหว่างช่วงพัฒนาขีดความสามารถด้าน AI การพยายามนำฟีเจอร์ AI ไปใช้งานในสภาพแวดล้อมโครงสร้างพื้นฐานที่ไม่มีระเบียบมักก่อให้เกิดระบบที่ดูแลรักษาและขยายขนาดได้ยาก Gradion ประเมินความพร้อมด้านโครงสร้างพื้นฐานในขั้นตอนกำหนดขอบเขตของทุกความร่วมมือด้านขีดความสามารถ AI

ขีดความสามารถด้าน AI ในทีมวิศวกรรมส่งผลต่อความเร็วในการส่งมอบอย่างไร?

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