Genie - On-Call Copilot ที่ขับเคลื่อนด้วย Generative AI ของ Uber

• การรักษาระบบปฏิบัติการ on-call ที่แข็งแกร่งท่ามกลางสภาพแวดล้อมทางเทคโนโลยีที่เปลี่ยนแปลงอย่างรวดเร็วเป็นสิ่งสำคัญต่อการทำให้บริการทำงานได้อย่างราบรื่น
• ทีมวิศวกรรมแพลตฟอร์มกำลังเผชิญความยากลำบากในการจัดการตาราง on-call การตอบสนองต่อ incident การสื่อสารในช่วงเวลาสำคัญ และการให้การสนับสนุนลูกค้าที่มีประสิทธิภาพในช่อง Slack® อย่างมีประสิทธิผล
• บทความนี้อธิบาย Genie ซึ่งเป็น on-call copilot ที่ใช้ generative AI เพื่อเพิ่มประสิทธิภาพการสื่อสารและการตอบคำถามกับวิศวกร on-call

เจาะลึกเพิ่มเติม: ปัญหาและแรงจูงใจ

• ที่ Uber หลายทีม เช่น ทีม Michelangelo มีช่องทางสนับสนุนบน Slack ที่ผู้ใช้ภายในสามารถเข้ามาขอความช่วยเหลือได้
• ในช่องเหล่านี้มีคำถามถูกถามเฉลี่ย 45,000 ข้อต่อเดือน
• ปริมาณคำถามที่มากและเวลารอคำตอบที่ยาวนานทำให้ประสิทธิภาพการทำงานของทั้งผู้ใช้และวิศวกร on-call ลดลง

กระบวนการที่ยุ่งยาก

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

ค้นหาข้อมูลได้ยาก

• คำถามจำนวนมากสามารถตอบได้จากเอกสารที่มีอยู่แล้ว แต่ข้อมูลกระจัดกระจายอยู่ใน Uber internal wiki ที่ชื่อ Engwiki, internal Stack Overflow และแหล่งอื่น ๆ ทำให้ยากต่อการค้นหาคำตอบที่ต้องการ
• ส่งผลให้ผู้ใช้มักถามคำถามเดิมซ้ำ ๆ และทำให้เกิดความต้องการ on-call support สูงในช่อง Slack หลายร้อยช่อง

ความท้าทายด้านสถาปัตยกรรม

• ในการสร้าง on-call copilot ทีมต้องเลือกว่าจะ fine-tune โมเดล LLM หรือใช้ Retrieval-Augmented Generation (RAG)
• การ fine-tune ต้องใช้ข้อมูลที่คัดสรรมาอย่างดี ซึ่งมีตัวอย่างคุณภาพสูงและหลากหลายเพื่อให้ LLM เรียนรู้ได้
• นอกจากนี้ยังต้องใช้ทรัพยากรคอมพิวต์เพื่อทำให้โมเดลทันสมัยอยู่เสมอด้วยตัวอย่างใหม่ ๆ
• ในทางกลับกัน RAG ไม่จำเป็นต้องมีตัวอย่างที่หลากหลายตั้งแต่เริ่มต้น
• แนวทางนี้ช่วยย่นระยะเวลาในการเปิดตัว copilot ดังนั้นเราจึงเลือกใช้วิธีนี้กับ copilot

การสร้าง on-call copilot มีความท้าทายหลายด้าน เช่น การแก้ปัญหา hallucination การปกป้องแหล่งข้อมูล และการปรับปรุงประสบการณ์ผู้ใช้ ต่อไปนี้คือภาพรวมว่าแต่ละปัญหาถูกแก้อย่างไร

สำหรับ hallucination ทีมให้ความสำคัญกับประเด็นต่อไปนี้:

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

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

เพื่อปรับปรุงประสบการณ์ผู้ใช้ ทีมออกแบบดังนี้:

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

ทีมได้แก้ไขความท้าทายเหล่านี้ในการพัฒนา on-call copilot ที่เชื่อถือได้ ใช้งานง่าย และปลอดภัย

วิเคราะห์โครงสร้างเชิงลึก

• มาดูสถาปัตยกรรมของ on-call copilot Genie กัน
• โดยสรุป ทีม scrape แหล่งข้อมูลภายใน เช่น internal wiki ของ Uber, internal Stack Overflow และเอกสารข้อกำหนดทางวิศวกรรม แล้วใช้ OpenAI embedding model เพื่อสร้างเวกเตอร์จากแหล่งข้อมูลเหล่านี้
• embedding เหล่านี้จะถูกเก็บไว้ใน vector database
• จากนั้นเมื่อผู้ใช้โพสต์คำถามในช่อง Slack คำถามจะถูกแปลงเป็น embedding
• บริการจะค้นหา embedding ที่เกี่ยวข้องกับคำถามจาก vector database
• ผลลัพธ์ที่ทำดัชนีด้วย embedding จะถูกใช้เป็น prompt ให้กับ LLM เพื่อสร้างคำตอบ

ขั้นตอน push artifact สำหรับการเตรียมข้อมูล การสร้าง embedding และการ serving สามารถทำให้เป็นรูปแบบทั่วไปสำหรับแอปพลิเคชัน RAG ที่ใช้ Apache Spark™ ได้ และขั้นตอนทั่วไปเหล่านี้เป็นพื้นฐานของแอปพลิเคชัน RAG

ETL

การเตรียมข้อมูล

• แอป Spark ดึงเนื้อหาจากแต่ละแหล่งข้อมูลผ่าน Uber's Engwiki หรือ Uber Stack Overflow API
• ในขั้นตอนเตรียมข้อมูลนี้ จะได้ผลลัพธ์เป็น Spark dataframe
• schema ประกอบด้วยคอลัมน์หนึ่งเป็นลิงก์ Engwiki และอีกคอลัมน์เป็นเนื้อหาของ Engwiki โดยทั้งคู่เป็นชนิด string

การสร้าง embedding

• หลังจาก scrape ข้อมูลแล้ว จะสร้าง embedding ด้วย OpenAI embedding model และ push ไปยัง Terrablob ซึ่งเป็น Blob storage ของ Uber
• embedding ที่สร้างขึ้นสามารถเข้าถึงได้เฉพาะผ่านช่อง Slack ที่เกี่ยวข้องกับพื้นที่ Engwiki นั้น
• รูปแบบผลลัพธ์คือ dataframe ที่มี schema ซึ่งแมปเนื้อหาแต่ละ chunk เข้ากับเวกเตอร์ของ chunk นั้น
• เนื้อหาใน internal wiki ของ Uber ถูกแบ่งเป็น chunk ด้วย langchain และ embedding ถูกสร้างจาก OpenAI ผ่าน PySpark UDF

Pusher

• แสดงวิธี push เวกเตอร์ไปยัง Terrablob
• แสดงลักษณะการ push เวกเตอร์
• มีการ trigger bootstrap job เพื่อรวบรวมข้อมูลจาก data source ไปยัง Sia
• Sia คือโซลูชัน vector database ภายในของ Uber
• จากนั้นจะ trigger Spark job สองงานเพื่อสร้างและ merge index พร้อมทั้งรวบรวมข้อมูลไปยัง Terrablob
• leaf ทั้งหมดจะซิงก์และดาวน์โหลด base index และ snapshot ที่เก็บอยู่ใน Terrablob
• ระหว่างการค้นหา query จะถูกส่งตรงไปยังแต่ละ leaf

Knowledge Service

• Genie มี backend service ชื่อว่า Knowledge Service
• มันจะแปลง query ที่เข้ามาเป็น embedding ก่อน จากนั้นดึง chunk ที่เกี่ยวข้องมากที่สุดจาก vector database เพื่อตอบทุกคำขอของ query ที่เข้ามา

การติดตามค่าใช้จ่าย

• สำหรับการติดตามค่าใช้จ่าย เมื่อ Slack client หรือแพลตฟอร์มอื่นเรียกใช้ Knowledge Service จะมีการส่ง UUID ไปยัง Knowledge Service
• จากนั้น Knowledge Service จะส่ง UUID ต่อไปยัง Michelangelo Gateway ผ่าน context header
• Michelangelo Gateway เป็นบริการ pass-through สำหรับ LLM ดังนั้นจึงสามารถเพิ่ม UUID นี้ลงใน audit log ที่ใช้ติดตามค่าใช้จ่ายได้

การประเมินประสิทธิภาพของ Genie

วิธีการวัด

• ผู้ใช้สามารถให้ feedback ได้ทันทีบน Slack โดยคลิกปุ่มที่เกี่ยวข้องในคำตอบของ Genie

• ผู้ใช้มีตัวเลือกดังต่อไปนี้:

  • แก้ไขได้แล้ว: คำตอบแก้ปัญหาได้อย่างสมบูรณ์
  • มีประโยชน์: คำตอบช่วยได้บางส่วน แต่ผู้ใช้ยังต้องการความช่วยเหลือเพิ่มเติม
  • ไม่เป็นประโยชน์: คำตอบผิดหรือไม่เกี่ยวข้อง
  • ไม่เกี่ยวข้อง: ผู้ใช้ต้องการการสนับสนุนจาก on-call และ Genie ไม่สามารถช่วยได้ (เช่น code review)

• เมื่อผู้ใช้ทิ้ง feedback ไว้ Slack plugin จะหยิบข้อมูลนี้ขึ้นมาและสตรีม feedback พร้อม metadata ที่เกี่ยวข้องไปยัง Hive table โดยใช้ Kafka topic เฉพาะ

• จากนั้นจึงนำ metric เหล่านี้ไปแสดงผลบน dashboard ในภายหลัง

การประเมินประสิทธิภาพ

• Genie เปิดให้ผู้ใช้มีตัวเลือกในการรันการประเมินแบบกำหนดเองได้
• ผู้ใช้สามารถประเมิน hallucination ความเกี่ยวข้องของคำตอบ หรือ metric อื่น ๆ ที่มองว่าสำคัญต่อ use case ของตน
• การประเมินนี้สามารถใช้เพื่อปรับแต่งองค์ประกอบ RAG ที่เกี่ยวข้องทั้งหมด เช่น retrieval และ generation ให้ดีขึ้น

กระบวนการประเมินเป็น ETL pipeline แยกต่างหากที่ใช้คอมโพเนนต์ Michelangelo ที่มีอยู่แล้ว โดย context และคำตอบของ Genie จะถูกดึงมาจาก Hive แล้ว join กับข้อมูลที่เกี่ยวข้องอื่น ๆ เช่น Slack metadata และ feedback ของผู้ใช้ จากนั้นประมวลผลและส่งต่อไปยัง Evaluator ส่วน Evaluator จะรับ prompt ที่กำหนดไว้และรัน LLM ในฐานะ Judge metric ที่ระบุจะถูกดึงออกมาและรวมไว้ในรายงานการประเมิน ซึ่งผู้ใช้สามารถดูได้ผ่าน UI

การประเมินเอกสาร

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

แสดง workflow ของแอปประเมินเอกสาร หลังจาก scrape ข้อมูลแล้ว เอกสารใน knowledge base จะถูกแปลงเป็น Spark dataframe โดยแต่ละแถวของ dataframe แทนเอกสารหนึ่งฉบับใน knowledge base จากนั้นจะเรียกใช้ LLM ในฐานะ Judge เพื่อประมวลผลการประเมิน โดยใช้ custom evaluation prompt เพื่อป้อนข้อมูลให้ LLM และ LLM จะส่งกลับคะแนนการประเมินพร้อมคำอธิบายของคะแนนนั้น รวมถึงข้อเสนอแนะที่นำไปปฏิบัติได้เพื่อยกระดับคุณภาพของแต่ละเอกสาร metric ทั้งหมดนี้จะถูกเผยแพร่เป็นรายงานการประเมินที่ผู้ใช้เข้าถึงได้ผ่าน Michelangelo UI

แนวทางแก้ปัญหาสำหรับความท้าทายต่าง ๆ

• เพื่อลด hallucination ทีมได้เปลี่ยนวิธีส่ง prompt ที่ได้จาก vector database ไปยัง LLM
  • สำหรับทุกผลลัพธ์ที่ได้จาก vector database จะมีการเพิ่ม source URL ที่เกี่ยวข้องพร้อม partial context อย่างชัดเจน
  • ขอให้ LLM ตอบโดยอิงเฉพาะ sub-context ต่าง ๆ ที่ให้มา และส่งกลับ source URL ที่ใช้อ้างอิงคำตอบ
  • พยายามให้มี source URL สำหรับทุกคำตอบ
• เพื่อป้องกันไม่ให้ข้อมูลรั่วไหลไปยัง Slack สำหรับผู้ที่ไม่มีสิทธิ์เข้าถึงแหล่งข้อมูลสำคัญ หรือระหว่างการสร้าง embedding ด้วย OpenAI ทีมได้คัดสรรแหล่งข้อมูลล่วงหน้าซึ่งวิศวกร Uber ส่วนใหญ่สามารถเข้าถึงได้อย่างกว้างขวาง และอนุญาตให้ใช้เฉพาะแหล่งข้อมูลเหล่านั้นในการสร้าง embedding
• เพื่อเพิ่มศักยภาพของ Genie ในการตอบคำถามให้สูงสุด ทีมได้พัฒนา interaction mode ใหม่
  • ในโหมดนี้ ผู้ใช้สามารถถามคำถามต่อได้สะดวกขึ้น และถูกกระตุ้นให้อ่านคำตอบของ Genie อย่างรอบคอบมากขึ้น
  • หาก Genie ไม่สามารถตอบคำถามได้ ผู้ใช้สามารถ escalate ปัญหาไปยัง on-call support ได้อย่างง่ายดาย

ใน interaction mode ใหม่นี้ เมื่อผู้ใช้ถามคำถาม Genie จะตอบพร้อมปุ่ม next-step action ที่เตรียมไว้ให้ ผู้ใช้จึงสามารถใช้ปุ่มเหล่านี้เพื่อถามต่อ ทำเครื่องหมายว่าคำถามได้รับการแก้ไขแล้ว หรือขอความช่วยเหลือจากมนุษย์ได้อย่างง่ายดาย

ผลลัพธ์

• นับตั้งแต่เปิดตัวในเดือนกันยายน 2023 Genie ได้ขยายการใช้งานไปยังช่อง Slack 154 ช่อง และตอบคำถามไปแล้วมากกว่า 70,000 ข้อ
• Genie มีอัตราความมีประโยชน์ 48.9% ซึ่งแสดงให้เห็นว่าประสิทธิผลของมันกำลังเพิ่มขึ้น
• คาดว่าตั้งแต่เปิดตัวจนถึงปัจจุบัน Genie ช่วยประหยัดเวลาทางวิศวกรรมไปแล้ว 13,000 ชั่วโมง

อนาคต

• Genie เป็น Slack bot ล้ำสมัยที่ออกแบบมาเพื่อลดความซับซ้อนของการจัดการ on-call เพิ่มประสิทธิภาพการตอบสนองต่อ incident และปรับปรุงการทำงานร่วมกันของทีม
• Genie ถูกพัฒนาขึ้นโดยเน้นทั้งความเรียบง่ายและประสิทธิภาพ ทำหน้าที่เป็นผู้ช่วยแบบครบวงจรและช่วยให้ทีมวิศวกรรมจัดการภารกิจ on-call ได้อย่างราบรื่น
• on-call assistant copilot ตัวนี้อาจเปลี่ยนประสบการณ์โดยรวมของวิธีที่ผู้ใช้และวิศวกร on-call โต้ตอบและมีส่วนร่วมกันภายในช่อง Slack ของแต่ละแพลตฟอร์ม
• นอกจากนี้ยังอาจเปลี่ยนประสบการณ์ภายในแต่ละผลิตภัณฑ์ เช่น Michelangelo หรือ IDE ให้ผู้ใช้สามารถค้นหาความช่วยเหลือเฉพาะผลิตภัณฑ์ได้ทั้งในช่อง Slack ของผลิตภัณฑ์หรือภายในตัวผลิตภัณฑ์เอง โดยไม่ต้องรอ on-call support

บทสรุป

• on-call assistant copilot Genie ได้พลิกโฉมวิธีที่ทีมวิศวกรรมจัดการงาน on-call
• ด้วยการผลักดันการแก้ปัญหาอัตโนมัติและให้การวิเคราะห์เชิงลึก Genie ช่วยให้ทีมจัดการความรับผิดชอบด้าน on-call ได้อย่างมีประสิทธิภาพและได้ผล

ความเห็นของ GN⁺

• Genie เป็น on-call copilot ที่น่าสนใจซึ่งช่วยประหยัดเวลาของวิศวกรและยกระดับประสบการณ์ผู้ใช้ ด้วยการตอบคำถามของผู้ใช้ในช่อง Slack จำนวนมากของ Uber
• ความสำเร็จของ Genie แสดงให้เห็นถึงการผสานพลังระหว่างเทคโนโลยีแมชชีนเลิร์นนิงกับความเชี่ยวชาญของมนุษย์อย่างทรงพลัง โดยอาศัยข้อมูลจำนวนมากและ LLM เพื่อให้คำตอบที่แม่นยำและมีประโยชน์ต่อคำถาม
• อย่างไรก็ตาม Genie ยังมีข้อจำกัดและพื้นที่ให้ปรับปรุงอยู่ โดยยังไม่สามารถแก้ปัญหา hallucination ได้อย่างสมบูรณ์ และบางครั้งอาจให้ข้อมูลที่ไม่ถูกต้องหรือชวนให้เข้าใจผิด จึงต้องปรับปรุงระบบผ่านการติดตามอย่างต่อเนื่องและ feedback จากผู้ใช้
• อีกประเด็นที่ต้องพิจารณาคือความปลอดภัยของข้อมูลและความเป็นส่วนตัว เนื่องจากข้อมูลที่ Genie จัดการอาจมีความอ่อนไหวและเป็นความลับ จึงจำเป็นต้องมีการจัดการอย่างปลอดภัยและการควบคุมสิทธิ์เข้าถึง
• ในอนาคต Genie อาจพัฒนาไปในทิศทางของการยกระดับคุณภาพคำตอบ รวมแหล่งข้อมูลเพิ่มขึ้น และเสริมความปลอดภัยให้แข็งแกร่งยิ่งขึ้น อีกทั้งยังอาจขยาย copilot ในลักษณะเดียวกันไปยังส่วนงานธุรกิจอื่น ๆ ได้
• ตั้งแต่การสนับสนุนลูกค้าอัตโนมัติ การช่วยด้านการขาย ไปจนถึงการช่วยเขียนโค้ด ผู้ช่วยที่ขับเคลื่อนด้วย AI สามารถประยุกต์ใช้กับงานได้หลากหลาย เครื่องมือเหล่านี้ช่วยเพิ่มประสิทธิภาพการทำงานของพนักงานและปรับปรุงประสบการณ์ผู้ใช้ได้
• โดยรวมแล้ว Genie เป็นกรณีศึกษาที่น่าสนใจซึ่งแสดงให้เห็นว่า AI และความเชี่ยวชาญของมนุษย์สามารถนำไปสู่วิธีทำงานและการบริการลูกค้าที่ดียิ่งขึ้นได้อย่างไร เทคโนโลยีลักษณะนี้จะยังคงพัฒนาต่อไป และคาดว่าจะส่งผลสำคัญต่อวิธีที่เราทำงานและมีปฏิสัมพันธ์กัน