# Genie - Uber의 생성형 AI 기반 On-Call Copilot > Clean Markdown view of GeekNews topic #17406. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=17406](https://news.hada.io/topic?id=17406) - GeekNews Markdown: [https://news.hada.io/topic/17406.md](https://news.hada.io/topic/17406.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2024-10-25T09:16:21+09:00 - Updated: 2024-10-25T09:16:21+09:00 - Original source: [uber.com](https://www.uber.com/en-IN/blog/genie-ubers-gen-ai-on-call-copilot/) - Points: 4 - Comments: 0 ## Summary Uber의 온콜 코파일럿 Genie가 어떻게 엔지니어링 팀의 온콜 업무를 혁신하고 있는지를 설명합니다. Genie는 생성형 AI를 활용하여 질문에 대한 정확하고 유용한 답변을 제공함으로써 엔지니어들의 시간을 절약하고 사용자 경험을 향상시킵니다. 또한, Genie의 성공은 기계 학습 기술과 인간 전문 지식의 강력한 결합을 보여주며, 향후 더 많은 데이터 소스를 통합하고 보안을 강화하는 방향으로 발전할 가능성을 제시합니다. ## Topic Body - 빠르게 변화하는 기술 환경에서 강력한 온콜 운영을 유지하는 것은 원활한 서비스 기능을 보장하는 데 중요함 - 플랫폼 엔지니어링 팀은 온콜 일정, 사고 대응, 중요한 순간의 커뮤니케이션 및 Slack® 채널에서의 강력한 고객 지원을 효율적으로 관리하는 데 어려움을 겪고 있음 - 온콜 엔지니어와의 커뮤니케이션 및 질문 답변을 최적화하기 위해 생성적 AI를 사용하는 온콜 코파일럿 Genie에 대해 설명함 ### 더 자세히 살펴보기: 문제와 동기 - Uber에서 Michelangelo 팀과 같은 다양한 팀은 내부 사용자가 도움을 요청할 수 있는 Slack 지원 채널을 가지고 있음 - 이러한 채널에서는 월 평균 45,000개의 질문이 제기됨 - 많은 양의 질문과 긴 응답 대기 시간은 사용자와 온콜 엔지니어의 생산성을 저하시킴 #### 번거로운 프로세스 - 일반적으로 사용자가 Slack 채널에 질문을 하면 온콜 엔지니어의 응답을 기다려야 함 - 온콜 엔지니어는 사용자의 초기 질문에 답하거나 더 많은 세부 정보를 요청함 - 사용자는 후속 질문을 하거나 더 많은 명확성을 구하거나 추가 정보를 제공할 수 있음 - 온콜 엔지니어의 응답을 다시 기다려야 하는 상황이 발생함 - 여러 번의 주고받는 커뮤니케이션 끝에 사용자의 질문이 해결됨 ### 정보 찾기 어려움 - 많은 질문들이 기존 문서를 참조하여 답변할 수 있지만, Engwiki라고 하는 Uber의 내부 위키, 내부 Stack Overflow 및 기타 위치에 정보가 분산되어 있어 특정 답변을 찾기 어려움 - 결과적으로 사용자는 종종 동일한 질문을 반복적으로 하게 되어 수백 개의 Slack 채널에서 온콜 지원에 대한 높은 수요가 발생함 ### 아키텍처 과제 - 온콜 코파일럿을 구축하기 위해 LLM 모델을 파인튜닝할지 아니면 [Retrieval-Augmented Generation (RAG)](https://www.anyscale.com/blog/a-comprehensive-guide-for-building-rag-based-llm-applications-part-1)을 활용할지 선택함 - 파인튜닝에는 LLM이 학습할 수 있는 고품질의 다양한 예제가 포함된 큐레이션된 데이터가 필요함 - 또한 새로운 예제로 모델을 최신 상태로 유지하기 위한 컴퓨팅 리소스도 필요함 - 반면에 RAG는 처음부터 다양한 예제가 필요하지 않음 - 이는 코파일럿 출시 시간을 단축시켰으므로 우리는 코파일럿에 이 접근 방식을 선택함 온콜 코파일럿을 구축하는 데는 환각 문제 해결, 데이터 소스 보호, 사용자 경험 개선 등 몇 가지 과제가 있었음. 각 과제를 어떻게 해결했는지 개괄적으로 살펴보겠음. 환각에 대해서는 다음 사항에 중점을 둠: - 응답의 정확성: 질문에 대한 관련 지식을 검색하여 LLM 엔진이 잘못되거나 오해의 소지가 있는 정보를 생성하지 않도록 함 - 검증 메커니즘: 환각 가능성을 줄이기 위해 권위 있는 출처에 대해 코파일럿의 응답을 검증하는 방법을 구현함 - 지속적인 학습: 코파일럿이 가장 최신 데이터에 액세스할 수 있도록 하여 정확성을 높임 데이터 보안을 위해 Slack 채널에 노출될 수 없는 많은 데이터 소스가 있기 때문에 수집할 데이터 소스를 신중하게 선택함 사용자 경험을 개선하기 위해 다음과 같이 설계함: - 직관적인 인터페이스: 사용자가 코파일럿과 효율적으로 상호 작용할 수 있는 사용하기 쉬운 인터페이스를 설계함 - 피드백 루프: 코파일럿의 성능을 지속적으로 개선하기 위해 사용자가 응답에 대한 피드백을 제공할 수 있는 시스템을 만듦 신뢰할 수 있고 사용자 친화적이며 안전한 온콜 코파일럿을 개발할 때 이러한 과제를 해결함 ### 구조 심층 분석 - 온콜 코파일럿 Genie의 아키텍처를 살펴보겠음 - 요약하자면 Uber의 내부 위키, 내부 Stack Overflow, 엔지니어링 요구사항 문서와 같은 내부 데이터 소스를 스크랩하고 OpenAI 임베딩 모델을 사용하여 이러한 데이터 소스에서 벡터를 만듦 - 이러한 임베딩은 벡터 데이터베이스에 저장됨 - 그런 다음 사용자가 Slack 채널에 질문을 게시하면 질문이 임베딩으로 변환됨 - 서비스는 벡터 데이터베이스에서 질문과 관련된 관련 임베딩을 검색함 - 임베딩으로 인덱싱된 결과는 응답을 받기 위해 LLM에 대한 프롬프트로 사용됨 데이터 준비, 임베딩 및 서빙을 위한 아티팩트 푸시 단계는 Apache Spark™를 사용하는 RAG 애플리케이션으로 일반화할 수 있음. 이러한 일반적인 단계는 RAG 애플리케이션의 기초를 형성함 ### ETL #### 데이터 준비 - Spark 앱은 Uber의 Engwiki 또는 Uber Stack Overflow API를 사용하여 각 데이터 소스에서 콘텐츠를 가져옴 - 이 데이터 준비 단계에서 Spark 데이터프레임이 출력됨 - 스키마에는 한 열에 Engwiki 링크가, 다른 열에 Engwiki의 내용이 있으며 둘 다 문자열 형식임 #### 임베딩 생성 - 데이터가 스크랩되면 OpenAI 임베딩 모델을 사용하여 임베딩이 생성되고 Uber의 Blob 스토리지인 Terrablob으로 푸시됨 - 생성된 임베딩은 Engwiki 공간과 관련된 특정 Slack 채널을 통해서만 액세스할 수 있음 - 출력 형식은 청크 콘텐츠를 해당 청크의 해당 벡터에 매핑한 스키마를 가진 데이터프레임임 - Uber의 내부 위키 내용은 langchain을 사용하여 청크화되고 임베딩은 PySpark UDF를 통해 OpenAI에서 생성됨 ### 푸셔 - Terrablob으로 벡터를 푸시하는 방법을 보여줌 - 벡터가 푸시되는 방식을 보여줌 - 데이터 소스에서 Sia로 데이터를 수집하기 위해 부트스트랩 작업이 트리거됨 - Sia는 Uber의 내부 벡터 데이터베이스 솔루션 - 그런 다음 인덱스 빌드 및 병합을 위해 두 개의 Spark 작업이 트리거되고 Terrablob으로 데이터를 수집함 - 모든 리프가 Terrablob에 저장된 기본 인덱스와 스냅샷을 동기화하고 다운로드함 - 검색 중에 쿼리가 각 리프에 직접 전송됨 ### 지식 서비스 - Genie에는 Knowledge Service라는 백엔드 서비스가 있음 - 들어오는 쿼리를 먼저 임베딩으로 변환한 다음 벡터 데이터베이스에서 가장 관련성이 높은 청크를 가져와 모든 들어오는 쿼리에 대한 요청에 응답함 ### 비용 추적 - 비용 추적을 위해 Slack 클라이언트 또는 기타 플랫폼이 Knowledge Service를 호출할 때 UUID가 Knowledge Service로 전달됨 - 그런 다음 Knowledge Service는 컨텍스트 헤더를 통해 UUID를 Michelangelo Gateway로 전달함 - Michelangelo Gateway는 LLM에 대한 패스스루 서비스이므로 해당 UUID로 비용을 추적하는 데 사용되는 감사 로그에 추가할 수 있음 ### Genie 성능 평가 #### 측정 방법 - 사용자는 Genie의 답변에서 관련 버튼을 클릭하여 Slack에서 즉시 피드백을 제공할 수 있음 - 사용자에게 다음 중 선택할 수 있는 옵션을 제공함: - 해결됨: 답변이 문제를 완전히 해결함 - 도움 됨: 답변이 부분적으로 도움이 되었지만 사용자는 더 많은 도움이 필요함 - 도움 안 됨: 응답이 잘못되었거나 관련이 없음 - 관련 없음: 사용자는 온콜 지원이 필요하며 Genie는 도움을 줄 수 없음(코드 리뷰와 같은 경우) - 사용자가 피드백을 남기면 Slack 플러그인이 이를 선택하고 특정 Kafka 토픽을 사용하여 피드백과 관련 메타데이터를 Hive 테이블로 스트리밍함 - 나중에 대시보드에서 이러한 메트릭을 시각화함 #### 성능 평가 - Genie 사용자에게 사용자 정의 평가를 실행할 수 있는 옵션을 제공함 - 사용자는 환각, 답변 관련성 또는 사용 사례에 중요하다고 생각하는 기타 측정항목을 평가할 수 있음 - 이 평가는 검색 및 생성과 같은 모든 관련 RAG 구성 요소를 더 잘 조정하는 데 사용할 수 있음 평가 프로세스는 이미 구축된 Michelangelo 구성 요소를 사용하는 별도의 ETL 파이프라인임. Genie의 컨텍스트와 응답은 Hive에서 검색되어 Slack 메타데이터 및 사용자 피드백과 같은 기타 관련 날짜에 조인됨. 처리되어 Evaluator로 전달됨. Evaluator는 지정된 프롬프트를 가져와서 Judge로 LLM을 실행함. 지정된 메트릭이 추출되어 평가 보고서에 포함되며 사용자는 UI에서 이 보고서를 이용할 수 있음 #### 문서 평가 - 정확한 정보 검색은 소스 문서의 명확성과 정확성에 달려 있음 - 문서 자체의 품질이 낮으면 LLM이 아무리 잘 수행하더라도 좋은 성능을 낼 방법이 없음 - 따라서 문서를 평가하고 문서 품질을 개선하기 위한 실행 가능한 제안을 할 수 있는 능력은 효율적이고 효과적인 RAG 시스템에 필수적임 문서 평가 앱의 워크플로우를 보여줌. 데이터가 스크랩된 후 지식 베이스의 문서는 Spark 데이터프레임으로 변환됨. 데이터프레임의 각 행은 지식 베이스의 하나의 문서를 나타냄. 그런 다음 LLM을 Judge로 호출하여 평가가 처리됨. 여기서 사용자 지정 평가 프롬프트를 사용하여 LLM에 피드를 제공함. LLM은 평가 점수와 함께 점수에 대한 설명 및 각 문서의 품질을 개선하기 위한 실행 가능한 제안을 반환함. 이 모든 메트릭은 사용자가 Michelangelo UI에서 액세스할 수 있는 평가 보고서로 게시됨 ### 과제에 대한 솔루션 - 환각을 줄이기 위해 벡터 데이터베이스에서 얻은 프롬프트를 LLM으로 보내는 방식을 변경함 - 벡터 데이터베이스에서 얻은 모든 결과에 대해 부분 컨텍스트와 함께 해당 소스 URL을 명시적으로 추가함 - LLM에게 제공된 다양한 하위 컨텍스트에서만 답변을 제공하고 답변을 인용할 소스 URL을 반환하도록 요청함 - 모든 답변에 대한 소스 URL을 제공하려고 함 - OpenAI로 임베딩을 생성하거나 중요한 데이터 소스에 액세스할 수 없는 사람들에게 Slack으로 데이터 소스를 유출하지 않도록 하기 위해, 대부분의 Uber 엔지니어가 널리 사용할 수 있는 데이터 소스를 미리 큐레이션하고 임베딩 생성에 해당 데이터 소스만 사용하도록 허용함 - Genie가 질문에 답하는 잠재력을 극대화하기 위해 새로운 상호 작용 모드를 개발함 - 이 모드에서는 사용자가 보다 편리하게 후속 질문을 할 수 있고 Genie의 답변을 더 주의 깊게 읽도록 유도함 - Genie가 질문에 답할 수 없는 경우 사용자는 문제를 온콜 지원으로 쉽게 에스컬레이션할 수 있음 새로운 상호 작용 모드에서 사용자가 질문을 하면 Genie는 제공된 다음 단계 작업 버튼과 함께 대답함. 이러한 버튼을 사용하여 사용자는 후속 질문을 쉽게 하고, 질문을 해결된 것으로 표시하거나, 사람 지원에 문의할 수 있음 ### 성과 - 2023년 9월 출시 이후 Genie는 154개의 Slack 채널로 입지를 확대했으며 7만 개 이상의 질문에 답변함 - Genie는 그 효과가 증가하고 있음을 보여주는 48.9%의 유용성 비율을 자랑함 - 출시 이후 현재까지 13,000시간의 엔지니어링 시간을 절약한 것으로 추정됨 ### 미래 - Genie는 온콜 관리를 간소화하고 사고 대응을 최적화하며 팀 협업을 개선하도록 설계된 최첨단 Slack 봇임 - 단순성과 효과성에 중점을 두고 개발된 Genie는 종합적인 어시스턴트 역할을 하며 엔지니어링 팀이 온콜 책임을 원활하게 처리할 수 있도록 지원함 - 이 온콜 어시스턴트 코파일럿은 사용자와 온콜 엔지니어가 각 플랫폼의 Slack 채널 내에서 상호 작용하고 참여하는 방식의 전체 경험을 변화시킬 수 있음 - 또한 Michelangelo나 IDE와 같은 각 제품 내에서 사용자가 온콜 지원을 기다리지 않고도 제품별 Slack 채널이나 제품 내에서 제품별 도움말을 찾을 수 있는 경험을 변화시킬 수 있음 ### 결론 - 온콜 어시스턴트 코파일럿 Genie는 엔지니어링 팀이 온콜 업무를 관리하는 방식을 혁신함 - 자동 해결을 촉진하고 통찰력 있는 분석을 제공함으로써 Genie는 팀이 온콜 책임을 효율적이고 효과적으로 처리할 수 있도록 지원함 ### GN⁺의 의견 - Genie는 Uber의 수많은 Slack 채널에서 사용자 질문에 답변하여 엔지니어들의 시간을 절약하고 사용자 경험을 향상시키는 혁신적인 온콜 코파일럿임 - Genie의 성공은 기계 학습 기술과 인간 전문 지식의 강력한 결합을 보여줌. 질문에 대한 정확하고 유용한 답변을 제공하기 위해 대규모 데이터와 LLM을 활용함 - 그러나 Genie는 여전히 제한 사항과 개선의 여지가 있음. 환각 문제를 완전히 해결하지는 못했고, 때로는 부정확하거나 오도된 정보를 제공할 수 있음. 지속적인 모니터링과 사용자 피드백을 통해 시스템을 개선해야 함 - 또 다른 고려 사항은 데이터 보안과 개인정보 보호임. Genie가 처리하는 데이터는 민감하고 기밀일 수 있으므로 안전한 처리와 액세스 제어가 필수적임 - 향후 Genie는 답변의 품질을 높이고 더 많은 데이터 소스를 통합하며 보안을 강화하는 방향으로 발전할 수 있음. 또한 Genie와 유사한 코파일럿을 다른 비즈니스 영역으로 확장하는 것도 가능함 - 자동화된 고객 지원, 판매 지원, 심지어 코딩 지원에 이르기까지 AI 기반 어시스턴트는 다양한 작업에 적용될 수 있음. 이러한 도구는 직원의 생산성을 높이고 사용자 경험을 개선할 수 있음 - 전반적으로 Genie는 AI와 인간 전문 지식이 어떻게 더 나은 작업 방식과 고객 서비스로 이어질 수 있는지를 보여주는 흥미로운 사례임. 이러한 기술은 계속 진화할 것이며, 우리가 어떻게 일하고 상호 작용하는지에 중대한 영향을 미칠 것으로 예상됨 ## Comments _No public comments on this page._