เจฟฟ์ แชมเปญ Field CTO ที่ Cribl – สัมภาษณ์ซีรีส์

เจฟฟ์ แชมเปญ Field CTO ที่ Cribl มีประสบการณ์มากมายทั่วทั้งด้าน Observability, Enterprise Data, Product Strategy และ Technical Architecture ก่อนที่จะเข้าร่วม Cribl เขาเคยดำรงตำแหน่ง Director of Product Management ที่ Databricks และใช้เวลาเกิน 7 ปีที่ Splunk ในตำแหน่ง Senior Field Product, Architecture และ Global Systems Engineering นอกจากนี้เขายังมีประสบการณ์ในการเป็นผู้นำด้าน Systems Architecture ที่ BNY ConvergEx, Senior Engineering ที่ Premier Technology Solutions และการเป็นผู้นำด้าน Engineering ที่ Assist-2-Sell ซึ่งทำให้เขามีมุมมองที่กว้างขวางเกี่ยวกับวิธีการที่องค์กรต่างๆ รวบรวม, จัดการ, วิเคราะห์ และดำเนินการตามข้อมูลการดำเนินงานในระดับใหญ่

Cribl เป็นบริษัท Telemetry ระดับองค์กรที่มุ่งเน้นในการช่วยเหลือทีม IT, Security, SRE และ DevOps ในการรวบรวม, ประมวลผล, ส่ง, จัดเก็บ และวิเคราะห์ข้อมูล Observability และ Security โดยไม่ต้องถูกจำกัดโดยผู้ให้บริการเดียว บริษัทนี้มีตำแหน่งตัวเองว่าเป็น “AI Platform for Telemetry” โดยมีผลิตภัณฑ์ เช่น Cribl Stream สำหรับการรวบรวม Telemetry ในเวลาจริง, Cribl Edge สำหรับการรวบรวม Telemetry จุดสิ้นสุด, Cribl Search สำหรับการค้นหาข้อมูลในสถานที่ และ Cribl Lake สำหรับการจัดเก็บ ข้อส่งเสริมหลักของบริษัทคือการให้ความสามารถในการควบคุม, ความยืดหยุ่น และประสิทธิภาพที่ดีขึ้นแก่องค์กรเมื่อปริมาณ Telemetry เพิ่มขึ้น และการดำเนินงานที่ขับเคลื่อนด้วย AI ต้องการข้อมูลที่สะอาดและเข้าถึงได้ง่ายขึ้น

คุณได้ทำงานทั่วทั้ง Splunk, Databricks และ Cribl ซึ่งให้มุมมองที่หายากเกี่ยวกับข้อมูลองค์กร, Observability และโครงสร้างพื้นฐานในช่วงหลายปี จากมุมมองนั้น สิ่งที่รู้สึกแตกต่างอย่างแท้จริงเกี่ยวกับความท้าทายของ Observability ที่สร้างโดย AI ที่มีหน่วยงานคืออะไร?

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

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

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

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

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

ตัวแทนได้ทำตามที่ได้รับคำสั่ง; ข้อมูลที่ไว้วางใจแค่นั้น

ทำไมเครื่องมือ Observability แบบดั้งเดิมจึงมักไม่เพียงพอสำหรับการติดตามระบบ AI ที่มีหน่วยงาน?

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

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

เมื่อตัวแทน AI ล้มเหลว, องค์กรสามารถกำหนดสาเหตุของการล้มเหลวได้อย่างไรว่าเป็นโมเดล, ชั้นการดึงข้อมูล, ข้อพึ่งพา API, ปัญหาเรื่องสิทธิ์ หรือปัญหาโครงสร้างพื้นฐาน?

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

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

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

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

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

สัญญาณ MELT อื่นๆ ไม่ได้หายไป; เมตริกเกี่ยวกับการใช้โทเค็นและความล่าช้าสำคัญสำหรับต้นทุนและประสิทธิภาพ และบันทึกจากระบบพื้นฐานยังคงจำเป็น แต่สืบค้นคือสิ่งที่ทำให้พฤติกรรมของตัวแทน AI อ่านได้ในระดับใหญ่

การอภิปรายเกี่ยวกับ AI หลายครั้งยังคงมุ่งเน้นไปที่การหลอกลวงอย่างมาก คุณคิดว่าองค์กรกำลังประเมินความล้มเหลวในการดำเนินงาน เช่น การดึงข้อมูลที่ไม่ดี, การผสมผสานที่เสียหาย, การเพิ่มขึ้นของความล่าช้า หรือข้อมูลที่หายไปหรือไม่?

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

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

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

พื้นฐานยังคงเป็น MELT แต่ความรับผิดชอบสำหรับระบบ AI ที่มีหน่วยงานต้องใช้การวางกรอบการประเมินบน Telemetry แบบดั้งเดิม เมตริก, อีเวนต์ และบันทึกจะเผยให้เห็นความล้มเหลวของโครงสร้างพื้นฐานและความผิดพลาดของการผสมผสานที่สามารถทำให้พฤติกรรมของตัวแทน AI ผิดพลาดได้ก่อนที่โมเดลจะตอบสนอง สืบค้นจะให้โซ่เหตุผลเพื่อทำความเข้าใจว่าทำไมถึงได้คำตอบนั้น แต่ไม่มีทางใดที่จะบอกว่าคำตอบนั้นถูกต้องหรือไม่ และนั่นคือที่ที่การประเมิน LLM-as-judge ช่วยเติมช่องว่าง การใช้ความสามารถ AI เหมือนเดิมที่ขับเคลื่อนตัวแทนสามารถใช้เพื่อประเมินพวกเขาได้ โดยการให้คะแนนเอาต์พุตสำหรับความถูกต้อง, ความมีเหตุผล และการทำงานให้เสร็จในระดับที่ไม่มีกระบวนการตรวจสอบของมนุษย์สามารถทำได้

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

บทบาทใดที่ท่อข้อมูล Telemetry สามารถช่วยให้ทีมความปลอดภัย, SRE, ข้อมูล และ AI ทำงานจากมุมมองที่ใช้ร่วมกันของพฤติกรรมของตัวแทน?

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

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

คุณเห็นองค์กรทำผิดพลาดอะไรบ้างเมื่อพวกเขาพยายามที่จะนำแนวทางปฏิบัติในการติดตามแบบดั้งเดิมมาใช้กับการใช้งาน AI ที่มีหน่วยงาน?

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

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

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

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

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

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