มอเช ซัมโบล, รองประธานฝ่ายโซลูชันลูกค้าของ Lightrun – ซีรีส์สัมภาษณ์

มอเช ซัมโบล, รองประธานฝ่ายโซลูชันลูกค้าของ Lightrun – มีประสบการณ์มากกว่าสองทศวรรษที่ครอบคลุมการวิศวกรรมซอฟต์แวร์, สถาปัตยกรรม, โครงสร้างพื้นฐานคลาวด์ และการเป็นผู้นำทางเทคนิคที่เผชิญหน้ากับลูกค้า ก่อนที่จะเข้าร่วม Lightrun ในปี 2022 เขาใช้เวลาเกือบทศวรรษที่ Google โดยดำรงตำแหน่งผู้นำหลายตำแหน่ง รวมถึงผู้จัดการวิศวกรรมลูกค้าคลาวด์ ซึ่งช่วยให้องค์กรต่างๆ นำเทคโนโลยีคลาวด์ของ Google มาใช้และขยายขนาด ในช่วงแรกของอาชีพของเขา Sambol ดำรงตำแหน่งวิศวกรรมและพัฒนาที่ Oracle, Sun Microsystems, BMC Software และ JPMorgan Chase ที่ Lightrun เขาเริ่มต้นด้วยการเป็นผู้นำฝ่ายวิศวกรรมโซลูชันระดับโลก ก่อนที่จะกลายเป็นรองประธานฝ่ายโซลูชันลูกค้า โดยมุ่งเน้นในการช่วยให้ลูกค้านำเทคโนโลยี Runtime Insights ของบริษัทมาใช้ และแปลความสามารถของเทคโนโลยีเหล่านี้ให้เป็นผลลัพธ์ทางธุรกิจและผลผลิตของนักพัฒนาที่วัดได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

นั่นคือสิ่งที่ทำให้บริบทการทำงานแบบไดนามิกเป็นชั้นการตรวจสอบที่เป็นธรรมชาติสำหรับการตัดสินใจที่สร้างโดย AI ในกระบวนการวิศวกรรม

Model Context Protocol (MCP) และชั้นการรวมอื่นๆ ช่วยให้เอเย่นต์เขียนโค้ดเรียนรู้จากพฤติกรรมที่แท้จริงโดยไม่ให้การเข้าถึงที่มากเกินไปหรือไม่ปลอดภัยต่อระบบการผลิตได้อย่างไร

MCP และการเข้าถึงเครื่องมือภายนอกที่ควบคุม (เช่น วรッปเปอร์ CLI) ให้เอเย่นต์เรียกใช้ความสามารถเฉพาะเจาะจง แทนที่จะให้การเข้าถึงที่กว้างขวางต่อระบบและเชื่อถือให้พฤติกรรมที่ดี เอเย่นต์ที่เชื่อมต่อกับเซิร์ฟเวอร์ MCP สำหรับบริบทการทำงานสามารถขอหลักฐานแบบอ่านเท่านั้น, ค่าแปรผัน, เส้นทางการเรียก, การตรวจสอบขอบเขต, โดยไม่ต้องสัมผัสกับการเขียน, ไม่ต้องมีการปรับใช้ใหม่ และไม่ต้องมีการรับรองความถูกต้องแบบยืนยันต่อสภาพแวดล้อมที่ซ่อนอยู่

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

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

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

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

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

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

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

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

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

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

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

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

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเยี่ยมชม Lightrun เพื่อเรียนรู้เพิ่มเติม