LLM 사용 사례(LLM Use Cases)

LLM 사용 사례(LLM Use Cases)

Confident AI가 지원하는 모든 사용 사례를 알아볼 수 있어요. 단순한 챗봇부터 복잡한 에이전트 시스템까지, 각 사용 사례마다 평가 요구사항이 다르고 그에 맞는 지표(metrics)와 기능이 준비돼 있죠. 어떤 시스템을 만들고 있는지에 따라 평가 포인트가 어떻게 달라지는지 살펴볼게요.

출처: 문서

본문

모든 사용 사례에서 지원

Confident AI는 단순한 챗봇부터 복잡한 에이전트 시스템까지 모든 유형의 LLM 애플리케이션을 평가할 수 있게 설계됐어요. 각 사용 사례는 저마다 독특한 평가 요구사항을 가지며, LLM 성능을 가장 정확하게 평가할 수 있도록 특화된 지표(metrics)와 기능을 제공해요.

사용 사례는 대략 이런 것들이에요:

  1. RAG QA: 문서 검색과 LLM 생성을 결합해 정확하고 출처 기반의 답변을 제공하는 시스템.
  2. 챗봇(Chatbots): 사용자와 자연스러운 대화를 나누도록 설계된 다중 턴(multi-turn) 대화형 AI 시스템.
  3. 글쓰기 어시스턴트(Writing Assistants): 제안·수정·개선을 제공해 사용자의 글쓰기를 돕는 AI 도구.
  4. 요약(Summarization): 핵심 정보를 유지하면서 긴 문서를 더 짧고 일관된 버전으로 압축하는 시스템.
  5. 자율 에이전트(Autonomous Agents): 복잡한 작업을 관리 가능한 단계로 나눠 독립적으로 수행하는 AI 시스템.
  6. Text-SQL: 자연어 질의를 SQL 데이터베이스 질의로 변환하는 시스템.
  7. 코드 생성(Code Generation): 자연어 설명으로 실행 가능한 코드를 만드는 시스템.

사용 사례는 서로 다른 시스템으로 만들 수 있어요. 시스템별로 평가 방식에 분명한 패턴이 보이는데:

  • 단순한 시스템(요약, 글쓰기 어시스턴트)은 출력 품질을 평가하는 사용 사례 특화 커스텀 지표에 더 집중해요
  • 복잡한 시스템(코드 생성, 자율 에이전트)은 시스템 지표와 함께 골든 expected_output에 대한 참조 기반 평가(reference-based evaluation), 그리고 디버깅을 위한 트레이싱(tracing)이 필요해요

Confident AI에서는 사용 사례당 프로젝트 공간을 하나씩 할당하는 걸 권해요.

RAG QA

RAG(Retrieval-Augmented Generation) QA 시스템은 문서 검색과 LLM 생성을 결합해 정확하고 출처 기반의 답변을 제공해요. 먼저 질의에 따라 관련 문서를 검색한 뒤, 그 문서들을 컨텍스트로 삼아 LLM이 근거 있는 응답을 생성하죠.

  • 의사가 관련 연구와 치료 가이드라인을 빠르게 찾도록 돕는 의료 지식 베이스
  • 변호사가 판례를 검색하고 요약을 만들도록 돕는 법률 리서치 어시스턴트
  • 고객 질문에 답하기 위해 관련 문서 섹션을 찾아주는 제품 문서 리트리버

의사가 관련 연구와 치료 가이드라인을 찾도록 돕는 의료 지식 베이스를 어떻게 평가하는지 살펴볼게요.

지표(Metrics)

의료 지식 베이스 예시에서는 시스템 특화 지표와 사용 사례 특화 지표를 섞어 쓰는 게 좋아요. RAG QA는 강한 시스템 성능과 도메인 특화 평가를 모두 요구하는 균형 잡힌 사용 사례죠. RAG QA 시스템에 권하는 지표는:

  • Answer Relevancy (일반 RAG): 답변이 질의를 얼마나 잘 다루는지
  • Faithfulness (일반 RAG): 답변이 검색된 컨텍스트에 의해 뒷받침되는지
  • Contextual Relevancy (일반 RAG): 검색된 문서가 질의와 얼마나 잘 일치하는지
  • Clinical Relevance (커스텀 G-Eval): 답변이 임상 진료에 얼마나 잘 적용되는지

이 예시에서 프롬프트 템플릿이 없는 답변이 테스트 케이스의 input이고, answer는 actual_output, 답변 생성에 검색되는 의료 문서는 retrieval_context가 돼요.

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

이 경우의 프롬프트는 평가 중 프롬프트 인사이트에 사용할 수 있어요.

챗봇(Chatbots)

챗봇은 사용자와 자연스럽고 다중 턴(multi-turn) 대화를 나누도록 설계된 대화형 다중 턴 AI 시스템이에요. 고객 서비스부터 정보 검색까지 다양한 작업을 처리하면서 대화 전반의 맥락을 유지할 수 있죠.

  • 고객이 제품을 찾고 구매하도록 돕는 고객 지원 챗봇
  • 의료 제공자가 증상을 평가하고 일정을 예약하도록 돕는 환자 분류 시스템
  • 고객이 잔액을 확인하고 거래하도록 돕는 뱅킹 어시스턴트

고객이 제품을 찾고 구매하도록 돕는 고객 지원 챗봇을 평가하는 방법을 보여드릴게요.

지표(Metrics)

고객 지원 챗봇 예시에서는 RAG적인 측면과 대화적인 측면을 모두 봐요. 이 챗봇은 RAG와 다중 턴 기능을 모두 합친 것이므로, 일반 지표로는 RAG 지표와 대화 지표를 조합해서 써요:

  • Contextual Recall (일반 RAG): 챗봇이 관련 제품 정보를 얼마나 잘 검색하는지
  • Role Adherence (일반 대화): 챗봇이 유용하고 고객 중심의 페르소나를 얼마나 잘 유지하는지
  • Purchase Intent Support (커스텀 G-Eval): 챗봇이 고객을 구매 결정으로 얼마나 잘 이끄는지

이 예시에서 고객 질의는 ConversationalTestCase의 turns 안에 있는 LLMTestCase의 input이고, 챗봇의 응답은 actual_output, 답변 생성에 검색되는 제품 문서는 retrieval_context예요. 챗봇의 역할과 성격을 정의하는 시스템 프롬프트는 chatbot_role 파라미터로 제공해 줘야 해요.

ConversationalTestCase가 무엇인지는 여기에서 배울 수 있어요.

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

글쓰기 어시스턴트(Writing Assistants)

글쓰기 어시스턴트는 제안, 수정, 개선을 제공해 사용자의 글쓰기를 돕는 AI 도구예요. 사용자의 목소리를 유지하면서 문법, 스타일, 톤, 전반적인 콘텐츠 품질을 도와줄 수 있어요.

  • 매력적인 소셜 미디어 게시물과 콘텐츠를 만드는 데 도움을 주는 마케팅 라이터
  • 학생들이 에세이와 연구 논문을 개선하도록 돕는 학술 라이터 어시스턴트
  • 명확한 API 설명을 만드는 기술 문서 생성기

매력적인 소셜 미디어 게시물과 콘텐츠를 만드는 마케팅 라이터를 평가하는 방법을 보여드릴게요.

지표(Metrics)

마케팅 라이터 예시에서는 콘텐츠 품질과 포맷에 집중해요. 가이드에서 1-2개의 커스텀 지표와 2-3개의 일반 지표를 권하지만, 이 글쓰기 어시스턴트는 포맷 도구 외에는 시스템 복잡도가 거의 없는 비교적 단순한 경우예요. 주로 사용 사례 특화 평가로, 시스템 복잡도보다는 출력 품질에 초점을 맞춰요.

이 사용 사례는 시스템 자체보다 사용 사례 요구사항에 더 관련이 깊으므로, 세 가지 핵심 지표를 써요:

  • Tool Correctness (일반 에이전트): 포맷 도구가 얼마나 정확하게 적용되는지
  • Format Correctness (커스텀 DAG): 글이 지정된 포맷 요구사항을 얼마나 잘 충족하는지
  • Brand Voice Alignment (커스텀 G-Eval): 콘텐츠가 브랜드의 톤과 메시지에 얼마나 잘 맞는지

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

경고(Warning)

이 사용 사례가 스타일 가이드 같은 외부 컨텍스트를 참조하긴 하지만, RAG 파이프라인으로 테스트할 필요는 없어요. RAG 파이프라인 테스트는 검색 과정 자체가 불완전하거나 최적화가 필요할 때 가장 가치 있어요.

요약(Summarization)

텍스트 요약 시스템은 핵심 정보를 유지하면서 긴 문서를 더 짧고 일관된 버전으로 압축해요. 추출적(중요한 문장을 뽑아냄)이거나 추상적(핵심을 담은 새 텍스트 생성)일 수 있어요.

  • 대화록에서 실행 항목과 핵심 포인트를 생성하는 회의 어시스턴트
  • 과학자가 자기 분야의 새 논문을 빠르게 이해하도록 돕는 리서치 도구
  • 일일 뉴스 기사의 간결한 요약을 만드는 뉴스 애그리게이터

대화록에서 실행 항목과 핵심 포인트를 생성하는 회의 어시스턴트를 평가하는 방법을 볼게요.

지표(Metrics)

회의 어시스턴트 예시에서는 요약 품질과 정확성에 집중해요. 글쓰기 어시스턴트와 비슷하게, 요약도 복잡한 시스템 상호작용보다는 출력 품질이 핵심이에요. 생성된 콘텐츠의 품질에 평가가 더 집중되는 사용 사례죠. 시스템이 원문에 접근할 수 있고 검색이 필요 없다고 가정해요. 핵심 지표는:

  • Faithfulness (일반 RAG): 요약이 원문에서 환각(hallucination)을 일으키는지
  • Format Correctness (커스텀 DAG): 요약이 요구된 구조(예: 불릿 포인트, 섹션)를 얼마나 잘 따르는지
  • Conciseness (커스텀 G-Eval): 요약이 불필요한 세부사항 없이 핵심 정보를 얼마나 잘 담는지

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

자율 에이전트(Autonomous Agents)

자율 에이전트는 복잡한 작업을 관리 가능한 단계로 나눠 독립적으로 수행할 수 있는 AI 시스템이에요. 도구를 사용하고, 결정을 내리며, 피드백과 변화하는 조건에 따라 접근 방식을 조정할 수 있죠.

  • 개인화된 여행 일정을 만들고 숙소를 예약하는 여행 플래너
  • 이메일 보내기, 양식 작성 같은 웹 작업을 자동화하는 브라우저 에이전트
  • 투자 포트폴리오를 관리하고 거래를 실행하는 트레이딩 봇
  • 공급망 운영을 조율하는 로지스틱스 매니저

개인화된 여행 일정을 만들고 숙소를 예약하는 여행 플래너를 평가하는 방법을 차근차근 살펴볼게요.

지표(Metrics)

여행 플래너 예시에서는 시스템 실행에 집중해요. 단순한 사용 사례와 달리, 자율 에이전트는 복잡한 실행 흐름을 가진 시스템 중심(System-heavy)이라서요. 여행 플래너에서는 여행 특화 결과보다 핵심 에이전트 실행 지표에 집중해요:

  • Tool Correctness (일반 에이전트): 에이전트가 검색, 예약, 달력 API 같은 도구를 얼마나 정확하게 사용하는지
  • Task Completion (일반 에이전트): 에이전트가 전체 여행 계획 워크플로우를 얼마나 성공적으로 완료하는지

이 예시에서 사용자의 여행 요구사항은 테스트 케이스의 input, 최종 일정과 예약은 actual_output이에요. 여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

자율 에이전트는 트레이싱 설정을 강력히 권장해요. 트레이싱은 에이전트 안의 중첩 컴포넌트 중 기대대로 동작하지 않는 부분을 디버깅할 수 있게 해 주거든요.

Text-SQL

Text-SQL 시스템은 자연어 질의를 SQL 데이터베이스 질의로 변환해, 사용자가 일상 언어로 데이터베이스와 상호작용하게 해 줘요. 데이터베이스 스키마를 이해하고, 사용자 의도를 정확히 반영한 복잡한 SQL 질의를 생성할 수 있죠.

  • 데이터 분석가가 판매 데이터를 질의할 수 있게 하는 비즈니스 인텔리전스 도구
  • 과학자가 실험 결과를 질의할 수 있게 하는 리서치 데이터베이스

데이터 분석가가 판매 데이터를 질의하는 비즈니스 인텔리전스 도구를 평가하는 방법을 볼게요.

지표(Metrics)

비즈니스 인텔리전스 도구 예시에서는 SQL 생성 품질에 집중해요. Text-SQL 시스템은 보통 RAG 시스템으로 동작해요. 첫 단계에서 잠재적으로 큰 데이터베이스 구조에서 관련 스키마 정보를 검색하고, 생성 단계에서는 자연어 품질보다 SQL 정확성에 집중하죠:

  • Contextual Relevancy (일반 RAG): 검색된 스키마가 질의 의도와 얼마나 잘 일치하는지
  • Faithfulness (일반 RAG): 생성된 SQL이 검색된 스키마에 의해 뒷받침되는지
  • SQL Correctness (커스텀 DAG): 생성된 SQL이 문법 규칙과 모범 사례를 얼마나 잘 따르는지

이 예시에서 자연어 질의는 테스트 케이스의 input, 생성된 SQL은 actual_output, 검색된 스키마 정보는 retrieval_context예요. 트레이싱도 여기서 검색된 테이블과 SQL 실행 시간을 시각화하는 데 매우 유용해요.

데이터베이스 테이블은 보통 구조와 콘텐츠를 압축한 요약으로 인덱싱돼요. 예를 들어 "sales" 테이블은 "Contains daily sales records with columns for product_id, quantity, price, and customer_id. Used for tracking revenue and inventory."처럼 인덱싱될 수 있어요. 이렇게 하면 시스템이 질의 의도에 따라 관련 테이블을 빠르게 검색할 수 있어요.

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

코드 생성(Code Generation)

코드 생성 시스템은 코드가 무엇을 해야 하는지에 대한 자연어 설명으로 실행 가능한 코드를 만들어요. 프로그래밍 언어와 모범 사례를 이해하고, 지정된 요구사항을 충족하는 잘 문서화되고 유지보수 가능한 코드를 생성할 수 있죠.

  • 프론트엔드 컴포넌트와 API 엔드포인트를 만드는 프론트엔드 UI 생성기
  • 개발자가 기본 애플리케이션 기능을 만들도록 돕는 VS Code의 코드 생성기 도구

프론트엔드 컴포넌트와 API 엔드포인트를 만드는 프론트엔드 UI 생성기를 평가하는 방법을 보여드릴게요.

지표(Metrics)

프론트엔드 UI 생성기 예시에서는 시스템 실행과 코드 품질 모두에 집중해요. 모든 사용 사례 중 가장 복잡한 경우로, 에이전트의 실행과 생성된 코드 품질을 모두 신중히 평가해야 하는 시스템 중심 사용 사례죠. 집중할 지표는:

  • Task Completion (일반 에이전트): 에이전트가 전체 코드 생성 워크플로우를 얼마나 성공적으로 완료하는지
  • Code Correctness (일반 DAG): 생성된 코드가 오류 없이 실행되는지
  • Code Quality (커스텀 G-Eval): 생성된 코드가 이상적이고 프로덕션 준비된 코드와 얼마나 비슷한지

이 예시에서 자연어 요구사항은 테스트 케이스의 input, 생성된 코드는 actual_output이에요. 이 사용 사례에서는 트레이싱이 확실히 필요할 거예요.

코드 생성은 틀림없이 복잡하며, 제대로 동작하려면 expected_output이 필요해요. GitHub나 Cursor 같은 코드 생성 도구라면 contextual recall도 포함해, 에이전트가 이상적인 코드를 만들기 위해 관련 코드 파일을 검색할 수 있게 해야 해요.

여기를 클릭하면 이 지표들을 평가에 만들고 사용하는 법을 배울 수 있어요.

중요한 참고 사항

일부 사용 사례에서는 우리가 가장 적절하다고 생각하는 예시 지표를 나열했어요. 하지만 사용 사례가 겉보기에는 우리 것과 똑같아 보여도, 여러분의 특정 사용 사례에 맞게 이 지표들을 신중히 평가하고 조정해야 해요. 제안된 지표가 좋은 출발점이 될 수는 있지만, 지표를 만들 때 사용 사례에 대해 많은 가정을 했거든요.

아주 드물게, 일부 지표는 expected_output 값이 있는 테스트 케이스를 요구해요. 이렇게 라벨링된 데이터셋이 없다면 두 가지 선택지가 있어요:

  1. 데이터셋을 수동으로 라벨링하기 (권장)
  2. 라벨링된 데이터가 필요 없는 대체 지표 선택하기

더 알아보기