영상 링크: How to look at your data — Jeff Huber (Choma) + Jason Liu (567)
채널명: AI Engineer
데이터를 제대로 바라보는 방법 — Jeff Huber(Chroma) & Jason Liu(567) 핵심 요약
- 영상 제목의 한국어 번역: 데이터를 제대로 바라보는 방법 — Jeff Huber(Chroma) & Jason Liu(567)
- 발표자들은 AI 실무자들이 데이터 품질을 올리고 시스템을 개선하기 위해 ‘데이터를 직접 바라보는 것’의 중요성을 강조함.
- 입력 데이터(쿼리-문서 페어)에 대해 ‘Fast Eval’ 방식을 활용하면 저렴하고 빠르게 임베딩 모델 등 핵심 요소들을 평가하고 실질적인 성능 개선이 가능함을 설명.
- Fast Eval은 실제 쿼리-문서 페어(골든 데이터셋) 세트를 기반으로 다양한 임베딩을 실험하며 성공률(리콜 등) 지표를 체크하는 접근임.
- 공개 벤치마크나 LLM 기반 비용이 큰 평가 대신, 자신만의 데이터와 골든셋을 활용해 빠르게 반복 실험하는 것이 효율적임을 사례와 수치로 제시.
- 실전 예시로 weights & biases 챗봇 데이터를 활용, 다양한 임베딩 모델(예: text embedding 3 small, Gina v3, voyage 3 large 등)의 실제 성능을 비교함.
- Fast Eval을 통해 트위터 등에서 화제가 된 모델이 내 데이터에서도 효과적인지 직접 검증할 수 있음을 시연.
- 아웃풋 분석(대화 로그, 사용 행태 등)은 대화의 메타데이터 추출, 클러스터링, KPI 세분화로 이어져 제품 개선·도구 개발의 기반이 됨을 강조.
- 사용자 대화에서 불만, 재시도, 피드백 등 의미 있는 정보를 자동 추출해, 개선이 필요한 핵심 도메인과 개선 우선순위를 과학적으로 도출할 수 있음.
- Anthropic Cleo와 같은 사례, 실제 데이터 분석 파이프라인, 오픈소스 코드/노트북 리소스도 안내됨.
- 주요 메시지: 데이터 입출력 모두를 구체적으로 측정·분석해야 반복적이고 체계적인 성능 개선과 제품 로드맵 수립이 가능하다는 것을 입증.
세부 요약 - 주제별 정리
데이터 품질 개선에서 ‘데이터 직접 바라보기’가 근본적으로 중요함을 강조
- 발표자 Jeff Huber(Chroma)는 “측정할 수 없으면 관리할 수 없다”란 피터 드러커의 명언을 인용하며 데이터 관찰의 중요성을 역설.
- AI 시스템을 개선할 때 추측이나 비공식적 방법, 대형모델 평가에만 의존하는 대신 자신의 데이터를 주기적으로(15회 이상) 관찰해야 함을 반복 강조.
- 복잡한 측정이 아닌, 기본적인 관찰이 반복적이고 체계적 개선의 핵심임을 설파.
입력 데이터 평가에서는 Fast Eval 방식이 신속성과 효율성을 모두 달성함
- Fast Eval은 쿼리-문서 쌍의 실제 예시(골든셋)를 기준으로 리트리버의 성공률 등 핵심 지표를 빠르게 측정하는 방법임.
- MTeb 등의 공개 벤치마크는 참고용이지만, 자신의 데이터에 맞게 직접 성능을 측정하는 것이 더 효과적임.
- Fast Eval의 장점: 실험이 매우 저렴(몇 센트 수준)하며, 반복 실험이 쉬워 빠른 의사결정이 가능함.
- 쿼리가 부족할 경우 LLM을 활용해 실제 사용 사례에 유사한 쿼리를 자동 생성하여 데이터셋을 보강할 수 있음.
- 단순한 LLM 쿼리 생성은 실효성이 낮으나, LLM에게 쿼리 작성법을 학습시키는 방법을 적용하면 실제 사용자 쿼리와 유사도를 높일 수 있음.
실제 데이터 실험을 통해 얻은 임베딩 모델의 성능 차이는 공개 벤치마크와 다를 수 있음
- weights & biases 챗봇 프로젝트에서 4종 임베딩 모델 간 리콜@10 성능을 직접 측정.
- 실제 사용자 쿼리(ground truth)와 LLM이 만든 생성 쿼리(generated)의 결과 순서가 거의 비슷해야 신뢰성 높은 평가가 가능함을 확인.
- 사례에서 text embedding 3 small 모델이 성능이 가장 낮았고, MTeb에서 뛰어난 성능을 보인 Gina embedding v3 역시 현장 적용 결과 기대 이하였음.
- 실제 효율적으로 작동한 모델은 voyage 3 large였으며, 이는 Fast Eval 실험을 통해 경험적으로 도출됨.
- 종합 결과: “내 데이터에서 어떤 임베딩이 가장 좋은지”는 직접 Fast Eval을 통해 실험해야만 확실히 판단 가능.
오픈소스 리포트·노트북·코드를 통해 누구나 실험을 재현할 수 있게 개방함
- 발표에서 사용된 모든 코드, 실험 환경, 데이터셋 등은 research.tra.com에 QR코드로 공개.
- 상세한 리포트와 동영상(스크린샷 예시 포함)까지 제공되어 누구든 동일 과정을 자신의 데이터로 재현 가능함.
- 독자적인 실험은 물론, 제품화·서비스 적용까지 적용할 수 있도록 설계되어 있음.
출력 데이터 분석(대화 로그)의 중요성과 실전 적용 방법 체계적으로 소개
- Jason Liu(567)는 시스템 출력을(대화, 에이전트 실행 등) 주의 깊게 관찰해야 제품 방향성과 개선 포인트를 찾을 수 있다고 설명.
- 적은 유저 수일 땐 전수(수동) 검토도 가능하지만, 쿼리/대화 규모가 급증하면 전체 구조 분석이 필요함.
- 긴 대화, 도구 호출, 체인 실행 등 복잡한 출력 데이터에서 중요한 신호(예: 사용자 불만, 재시도, 오류 패턴)가 메타데이터 형태로 존재함을 강조.
대화 로그에서 추출한 메타데이터·클러스터 분석이 실제 제품 개선의 핵심 근거가 됨
- 전통적인 데이터 분석처럼 대화 로그에서 토픽, 사용 도구, 에러, 만족도/불만족 같은 메타데이터를 구조화해서 추출.
- 이 데이터를 임베딩하여 클러스터링, 세분화(세그멘트화)하고, 집단별 패턴/문제 영역을 규명.
- Anthropic Cleo의 사례처럼 클러스터 분석으로 실제로 코드 사용이 많았던 집단을 찾고, 그 도메인에 리소스 투자 계획을 세울 수 있음.
- 이를 위해 오픈소스 라이브러리 ‘cura’를 개발, 요약, 클러스터링, 계층 형성, KPI 간 비교를 일관된 파이프라인으로 제공.
구체적인 분석·클러스터링 파이프라인 예시(실제 데이터 활용)
- 예시 데이터(예: Gemini 대화 데이터)에 cura 파이프라인을 적용하는 절차 소개:
- 대화를 요약(Summary Model: 토픽·에러·불만 등 추출)
- 임베딩-클러스터링(예: 데이터 시각화, SEO, 인증 에러 등 도출)
- 하위/상위 클러스터에서 주요 테마(예: 데이터 분석, 테크 지원 등) 파악
- 이 분석 결과를 바탕으로 도구(예: 데이터 시각화, 인증 문제 해결), 마케팅, 프롬프트 수정보완 등 제품 우선순위 결정 가능.
클러스터별 KPI 비교를 통해 정확한 개선·무시·교육 포인트를 도출할 수 있음을 주장
- 전체 평균 KPI(예: factuality=0.5)는 해석이 모호하나, “특정 클러스터(예: 시간 필터 활용 쿼리)에서는 성능이 낮다”처럼 도메인별로 세분화할 경우 명확한 개선 방향 도출 가능.
- KPI가 낮은 집단, 사용량 많은데 성능 낮은 도구 등에 집행 리소스를 집중.
- KPI가 낮지만 사용자가 거의 없는 집단은 프롬프트 안내나 무시해도 무방.
- 이런 데이터 기반 의사결정은 단순히 모델(LLM)을 ‘좋게’ 만드는 것만이 아니라, 도구·인프라·UX 개선 등 다양한 측면의 조치를 이끌 수 있음.
실제 분석 사례와 제품 전략 수립 절차 구체적으로 안내
- 발표진은 weights and biases 대화 데이터를 오픈소스 Jupyter notebook(3개)으로 정리해 전체 클러스터링 및 데이터 기반 제품 개선 의사결정 사례 제공.
- 신규 고객/기존 고객 간 사용 행태 차이, 주요 사용 목적 변화 등 실전 통계 분석 패턴을 상세히 제시.
- 전체 메시지: 데이터 구조화-세분화-클러스터-KPI 비교 및 모니터링을 통해 반복적 실험→제품 로드맵 수립으로 이어지는 선순환을 실현할 수 있음을 입증.
실전 조언: 자신의 데이터에 맞춰 빠른 실험, 세그멘테이션, KPI 비교를 반복하라
- 처음엔 소규모, 단순 구조로 시작해 나중엔 고도화된 분석·모니터링으로 발전시키라고 권고.
- 입출력 데이터 모두 직접 살펴 KPI별 상태를 상세히 파악함으로써, “무엇을 개선하고, 무엇을 제작하고, 무엇을 무시해야 할지” 데이터로 결정할 수 있음을 재차 강조.
- 마지막에는 오픈소스 코드와 리소스를 QR코드로 안내하며, 적용법 익히기를 추천.