생성적 인공지능 애플리케이션 개발자 작업 흐름

2025-04-04

강력한 생성 AI 애플리케이션(Gen AI 앱)을 개발하려면 의도적인 계획, 신속한 개발 피드백 평가 루프 및 확장 가능한 프로덕션 인프라가 필요합니다. 이 워크플로에서는 초기 POC(개념 증명)에서 프로덕션 배포로 안내하는 권장되는 단계 시퀀스를 간략하게 설명합니다.

0. 필수 구성 요소

Gen AI 적합성 유효성을 검사하고 제약 조건을 식별하기 위한 요구 사항을 수집합니다.
솔루션 아키텍처를 디자인합니다. 에이전트 시스템 디자인 패턴 참조

1. 빌드

데이터 원본을 준비하고 필요한 도구를 만듭니다.
초기 프로토타입(POC)을 빌드하고 유효성을 검사합니다.
사전 프로덕션 환경에 배포합니다.

2. 평가 및 반복

사용자 피드백 수집 및 품질 측정
평가에 따라 에이전트 논리 및 도구를 구체화하여 품질 문제를 해결합니다.
에이전트 시스템의 품질을 지속적으로 개선하기 위해 SME(주제 전문가) 입력을 통합합니다.

3. 프로덕션

프로덕션 환경에 Gen AI 앱을 배포합니다.
성능 및 품질을 모니터링합니다.
실제 사용량에 따라 유지 관리 및 개선합니다.

이 워크플로는 반복적이어야 합니다. 각 배포 또는 평가 주기 후에는 이전 단계로 돌아가서 데이터 파이프라인을 구체화하거나 에이전트 논리를 업데이트합니다. 예를 들어 프로덕션 모니터링은 새로운 요구 사항을 표시하여 에이전트 디자인에 대한 업데이트를 트리거하고 또 다른 평가 라운드를 트리거할 수 있습니다. 이러한 단계를 체계적으로 수행하고 Databricks MLflow 추적, 에이전트 프레임워크 및 에이전트 평가 기능을 활용하여 사용자 요구를 안정적으로 충족하고 보안 및 규정 준수 요구 사항을 준수하며 시간이 지남에 따라 지속적으로 개선할 수 있는 고품질의 GEN AI 앱을 빌드할 수 있습니다.

0. 필수 구성 요소

Gen AI 애플리케이션 개발을 시작하기 전에 요구 사항 및 솔루션 디자인 수집과 같은 작업을 제대로 수행하는 데 시간이 걸리는 것이 얼마나 중요한지 과장할 수 없습니다.

요구 사항 수집에는 다음 단계가 포함됩니다.

Gen AI가 사용 사례에 적합한지 확인합니다.
사용자 환경을 정의합니다.
데이터 원본을 조사합니다.
성능 제약 조건을 설정합니다.
보안 제약 조건을 캡처합니다.

솔루션 디자인 에는 다음이 포함됩니다.

데이터 파이프라인을 매핑합니다.
필요한 도구를 식별합니다.
전체 시스템 아키텍처를 간략하게 설명합니다.

이 기초를 배치하여 후속 빌드, 평가 및 프로덕션 단계에 대한 명확한 방향을 설정합니다.

요구 사항 수집

명확하고 포괄적인 사용 사례 요구 사항을 정의하는 것은 성공적인 Gen AI 앱을 개발하는 데 중요한 첫 번째 단계입니다. 이러한 요구 사항은 다음과 같은 용도로 사용됩니다.

Gen AI 접근 방식이 사용 사례에 적합한지 여부를 결정하는 데 도움이 됩니다.
솔루션 디자인, 구현 및 평가 결정을 안내합니다.

세부 요구 사항을 수집하기 위해 처음에 시간을 투자하면 개발 프로세스의 뒷부분에서 중요한 문제를 방지하고 결과 솔루션이 최종 사용자 및 이해 관계자의 요구를 충족하는지 확인할 수 있습니다. 잘 정의된 요구 사항은 애플리케이션 수명 주기의 후속 단계를 위한 토대를 제공합니다.

사용 사례가 Gen AI에 적합한가요?

Gen AI 솔루션에 커밋하기 전에 고유한 강점이 요구 사항에 부합하는지 여부를 고려합니다. 생성 AI 솔루션이 적합한 몇 가지 예는 다음과 같습니다.

콘텐츠 생성: 이 작업을 수행하려면 정적 템플릿 또는 간단한 규칙 기반 논리를 사용하여 달성할 수 없는 새로운 또는 창의적인 콘텐츠를 생성해야 합니다.
동적 쿼리 처리: 사용자 쿼리는 개방형 또는 복잡하며 유연하고 컨텍스트 인식 응답을 요구합니다.
정보 합성: 사용 사례는 다양한 정보 원본을 결합하거나 요약하여 일관된 출력을 생성할 수 있습니다.
에이전트 시스템: 애플리케이션에는 프롬프트에 대한 응답으로 텍스트를 생성하는 것 이상이 필요합니다. 다음을 수행할 수 있어야 할 수 있습니다.
- 계획 및 의사 결정: 특정 목표를 달성하기 위한 다단계 전략을 수립합니다.
- 작업 수행: 외부 프로세스를 트리거하거나 작업을 수행하기 위해 다양한 도구를 호출합니다(예: 데이터 검색, API 호출, SQL 쿼리 실행, 코드 실행).
- 상태 유지 관리: 연속성을 활성화하기 위해 여러 상호 작용에서 대화 기록 또는 작업 컨텍스트를 추적합니다.
- 적응형 출력 생성: 이전 작업, 업데이트된 정보 또는 변경 조건에 따라 진화하는 응답 생성

반대로, 다음과 같은 상황에서는 Gen AI 접근 방식이 이상적이지 않을 수 있습니다.

이 작업은 매우 결정적이며 미리 정의된 템플릿 또는 규칙 기반 시스템으로 효과적으로 해결할 수 있습니다.
전체 필수 정보 집합이 이미 정적이거나 단순하고 닫힌 프레임워크에 적합합니다.
대기 시간이 매우 짧고(밀리초) 응답이 필요하며 생성 처리 오버헤드를 수용할 수 없습니다.
간단한 템플릿 응답은 의도한 사용 사례에 충분합니다.

중요합니다

아래 섹션에서는 P0, P1 및 P2 레이블 레이블 을 사용하여 상대적 우선 순위를 나타냅니다.

🟢 [P0] 항목은 중요하거나 필수입니다. 이 문제들은 즉시 다루어야 합니다.
🟡 [P1] 항목은 중요하지만 P0 요구 사항 후에 따를 수 있습니다.
⚪ [P2] 항목은 시간 및 리소스가 허용하는 대로 처리될 수 있는 우선 순위가 낮은 고려 사항 또는 향상된 기능입니다.

이러한 레이블은 팀이 즉각적인 주의가 필요한 요구 사항과 지연될 수 있는 요구 사항을 신속하게 확인할 수 있도록 도와줍니다.

사용자 환경

사용자가 Gen AI 앱과 상호 작용하는 방법과 예상되는 응답 종류를 정의합니다.

🟢 [P0] 일반적인 요청: 일반적인 사용자 요청은 어떻게 됩니까? 관련자로부터 예제를 수집합니다.
🟢 [P0] 예상 응답: 시스템에서 생성해야 하는 응답 유형(예: 짧은 답변, 긴 형식 설명, 창의적인 설명)?
🟡 [P1] 상호 작용 형식: 사용자가 애플리케이션과 상호 작용하는 방법(예: 채팅 인터페이스, 검색 창, 음성 도우미)?
🟡 [P1] 톤, 스타일, 구조: 생성된 출력이 어떤 톤, 스타일 및 구조를 채택해야 하나요(공식, 대화형, 기술, 글머리 기호 또는 연속 산문)?
🟡 [P1]오류 처리: 애플리케이션에서 모호하거나 불완전하거나 대상이 없는 쿼리를 어떻게 처리해야 하나요? 피드백을 제공하거나 설명을 요청해야 하나요?
⚪ [P2] 서식 지정 요구 사항: 출력에 대한 특정 서식 또는 프레젠테이션 지침(메타데이터 또는 추가 정보 포함)이 있나요?

데이터

Gen AI 앱에서 사용할 데이터의 특성, 원본 및 품질을 결정합니다.

🟢 [P0] 데이터 원본: 사용할 수 있는 데이터 원본은 무엇인가요?
- 각 원본에 대해 다음을 결정합니다.
  - 데이터가 구조화되었거나 구조화되지 않은가요?
  - 원본 형식(예: PDF, HTML, JSON, XML)은 무엇인가요?
  - 데이터는 어디에 있나요?
  - 사용할 수 있는 데이터의 양
  - 데이터에 액세스하는 방법
🟡 [P1] 데이터 업데이트: 데이터는 얼마나 자주 업데이트되는가? 업데이트를 처리하기 위한 메커니즘은 무엇인가요?
🟡 [P1] 데이터 품질: 알려진 품질 문제 또는 불일치가 있나요?
- 데이터 원본에 대한 품질 모니터링이 필요한지 고려합니다.

인벤토리 테이블을 만들어 이 정보를 통합하는 것이 좋습니다. 예를 들면 다음과 같습니다.

데이터 원본	출처	파일 형식	크기	업데이트 빈도
데이터 원본 1	유니티 카탈로그 볼륨	JSON (자바스크립트 객체 표기법)	10GB	매일
데이터 원본 2	퍼블릭 API	XML	NA(API)	실시간
데이터 원본 3	셰어포인트	PDF, .docx	500MB	매월

성능 제약 조건

Gen AI 애플리케이션에 대한 성능 및 리소스 요구 사항을 캡처합니다.

대기 시간

🟢 [P0] Time to First 토큰: 출력의 첫 번째 토큰을 전달하기 전에 허용되는 최대 지연 시간은 얼마인가요?
- 메모: 대기 시간은 일반적으로 p50(중앙값) 및 p95(95번째 백분위수)를 사용하여 평균 및 최악의 성능을 모두 캡처하도록 측정됩니다.
🟢 [P0] 완료 시간: 사용자에게 허용되는(완료 시간) 응답 시간은 얼마인가요?
🟢 [P0] 스트리밍 대기 시간: 응답이 스트리밍되는 경우 전체 대기 시간이 더 높아질 수 있나요?

확장성

🟡 [P1]동시 사용자 및 요청: 시스템에서 지원해야 하는 동시 사용자 또는 요청 수는 몇 개입니까?
- 참고: 확장성은 QPS(초당 쿼리) 또는 QPM(분당 쿼리)으로 측정되는 경우가 많습니다.
🟡 [P1] 사용 패턴: 예상되는 트래픽 패턴, 최대 부하 또는 사용량의 시간 기반 급증은 무엇인가요?

비용 제약 조건

🟢 [P0] 유추 비용 제한 사항: 유추 컴퓨팅 리소스에 대한 비용 제약 조건 또는 예산 제한은 무엇인가요?

평가

시간에 따라 Gen AI 앱을 평가하고 개선하는 방법을 설정합니다.

🟢 [P0] 비즈니스 KPI: 애플리케이션에 영향을 주어야 하는 비즈니스 목표 또는 KPI는 무엇입니까? 기준 값 및 대상을 정의합니다.
🟢 [P0] 관련자 피드백: 누가 애플리케이션 성능 및 출력에 대한 초기 및 지속적인 피드백을 제공합니까? 특정 사용자 그룹 또는 도메인 전문가를 식별합니다.
🟢 [P0] 품질 측정: 생성된 출력의 품질을 평가하는 데 사용할 메트릭(예: 정확도, 관련성, 안전성, 인적 점수)은 무엇인가요?
- 이러한 메트릭은 개발 중에 어떻게 계산되나요(예: 가상 데이터, 수동으로 큐레이팅된 데이터 세트에 대해)?
- 프로덕션 환경에서 품질은 어떻게 측정되나요(예: 실제 사용자 쿼리에 대한 응답 로깅 및 분석)?
- 오류에 대한 전반적인 허용 오차는 무엇인가요? (예를 들어 사소한 사실 부정확성의 특정 비율을 허용하거나 중요한 사용 사례에 대해 약 100개의% 정확성을 요구합니다.)
- 목표는 실제 사용자 쿼리, 합성 데이터 또는 둘의 조합에서 평가 집합으로 빌드하는 것입니다. 이 집합은 시스템이 발전함에 따라 성능을 평가하는 일관된 방법을 제공합니다.
🟡 [P1] 피드백 루프: 사용자 피드백을 수집(예: 엄지 손가락/아래로, 설문 조사 양식)하고 반복적인 개선을 추진하는 데 사용하려면 어떻게 해야 하나요?
- 피드백을 검토하고 통합하는 빈도를 계획합니다.

안전

보안 및 개인 정보 보호 고려 사항을 식별하세요.

🟢 [P0] 데이터 민감도: 특별한 처리가 필요한 중요한 데이터 요소 또는 기밀 데이터 요소가 있나요?
🟡 [P1] 액세스 제어: 특정 데이터 또는 기능을 제한하기 위해 액세스 제어를 구현해야 합니까?
🟡 [P1] 위협 평가 및 완화: 애플리케이션이 프롬프트 주입 또는 악의적인 사용자 입력과 같은 일반적인 세대 AI 위협으로부터 보호해야 합니까?

배치

Gen AI 솔루션이 통합, 배포, 모니터링 및 유지 관리되는 방식을 이해합니다.

🟡 [P1] 통합: Gen AI 솔루션은 기존 시스템 및 워크플로와 어떻게 통합되어야 하나요?
- 통합 지점(예: Slack, CRM, BI 도구) 및 필요한 데이터 커넥터를 식별합니다.
- Gen AI 앱과 다운스트림 시스템(예: REST API, 웹후크) 간에 요청 및 응답이 흐르는 방식을 결정합니다.
🟡 [P1] 배포: 애플리케이션 배포, 크기 조정 및 버전 관리 요구 사항은 무엇인가요? 이 문서에서는 MLflow, Unity 카탈로그, 에이전트 프레임워크, 에이전트 평가 및 모델 서비스를 사용하여 Databricks에서 엔드투엔드 수명 주기를 처리하는 방법을 설명합니다.
🟡 [P1] 프로덕션 모니터링 및 관찰 가능성: 프로덕션 환경에서 애플리케이션을 모니터링하려면 어떻게 해야 할까요?
- 로깅 및 추적: 전체 실행 추적을 캡처합니다.
- 품질 메트릭: 라이브 트래픽에서 주요 메트릭(예: 정확성, 대기 시간, 관련성)을 지속적으로 평가합니다.
- 경고 및 대시보드: 중요한 문제에 대한 경고를 설정합니다.
- 피드백 루프: 사용자 피드백을 프로덕션 환경에 통합(엄지 또는 아래로)하여 문제를 조기에 파악하고 반복적인 개선을 추진합니다.

예시

예를 들어 Databricks 고객 지원 팀에서 사용하는 가상의 에이전트 RAG 애플리케이션에 이러한 고려 사항 및 요구 사항이 적용되는 방식을 고려합니다.

지역	고려 사항	요구 사항
사용자 환경	상호 작용 형식입니다. 일반적인 사용자 쿼리 예제입니다. 예상 응답 형식 및 스타일입니다. 모호하거나 관련이 없는 쿼리 처리	Slack과 통합된 채팅 인터페이스입니다. 예제 쿼리: "클러스터 시작 시간을 줄이려면 어떻게 하나요?" "어떤 종류의 지원 계획이 있나요?" 코드 조각이 포함된 명확한 기술 응답 및 적절한 경우 관련 설명서에 대한 링크. 상황에 맞는 제안을 제공하고 필요할 때 엔지니어를 지원하도록 에스컬레이션합니다.
에이전트 논리	쿼리 이해 및 분류. 다단계 계획 및 의사 결정. 자율 도구 선택 및 실행. 상호 작용에 대한 상태 및 컨텍스트 관리. 오류 처리 및 대체 메커니즘.	결정론적 대체 방안을 사용하는 LLM 기반 계획입니다. 미리 정의된 도구 집합(예: 문서 검색 또는 Salesforce 검색 도구)과 통합합니다. 일관된 다중 턴 상호 작용 및 강력한 오류 복구를 위해 대화 상태를 유지 관리합니다.
데이터	데이터 원본의 수 및 형식입니다. 데이터 형식 및 위치입니다. 데이터 크기 및 업데이트 빈도입니다. 데이터 품질 및 일관성.	4개의 데이터 원본. 회사 설명서(HTML, PDF). 지원 티켓(해결됨) - JSON 형식. 커뮤니티 포럼 게시물(델타 테이블). Salesforce 연결기. Unity 카탈로그에 저장되고 매주 업데이트되는 데이터입니다. 총 데이터 크기: 5GB. 전용 문서 및 지원 팀에서 유지 관리하는 일관된 데이터 구조 및 품질입니다.
성능	허용되는 최대 대기 시간. 비용 제약 조건. 예상 사용량 및 동시성	최대 대기 시간 요구 사항입니다. 비용 제약 조건. 예상 최대 부하.
평가	평가 데이터 세트 가용성. 품질 메트릭. 사용자 피드백 컬렉션입니다.	각 제품 영역의 주제 전문가는 출력을 검토하고 잘못된 답변을 조정하여 평가 데이터 세트를 만드는 데 도움을 줍니다. 비즈니스 KPI. 지원 티켓 해결률 증가. 지원 티켓당 소요된 사용자 시간을 줄입니다. 품질 메트릭. LLM에서 판단한 답변의 정확성 및 관련성 LLM은 검색 정밀도를 판단합니다. 사용자 추천 또는 비추천. 피드백 컬렉션입니다. Slack은 좋아요/싫어요 기능을 제공하기 위해 설정됩니다.
안전	중요한 데이터 처리. 액세스 제어 요구 사항.	중요한 고객 데이터는 검색 원본에 없어야 합니다. Databricks Community SSO를 통한 사용자 인증
배치	기존 시스템과의 통합 배포 및 버전 관리.	지원 티켓 시스템과의 통합. Databricks 모델 서비스 엔드포인트로 배포된 에이전트입니다.

솔루션 디자인

추가 디자인 고려 사항은 에이전트 시스템 디자인 패턴을 참조하세요.

데이터 원본 및 도구

Gen AI 앱을 디자인할 때 솔루션을 구동하는 데 필요한 다양한 데이터 원본과 도구를 식별하고 매핑하는 것이 중요합니다. 여기에는 구조적 데이터 세트, 구조화되지 않은 데이터 처리 파이프라인 또는 외부 API 쿼리가 포함될 수 있습니다. 다음은 Gen AI 앱에 다양한 데이터 원본 또는 도구를 통합하는 데 권장되는 접근 방식입니다.

구조적 데이터

구조화된 데이터는 일반적으로 잘 정의된 테이블 형식(예: 델타 테이블 또는 CSV 파일)에 상주하며, 쿼리가 미리 결정되거나 사용자 입력에 따라 동적으로 생성되어야 하는 작업에 적합합니다. Gen AI 앱에 구조적 데이터를 추가하는 방법에 대한 권장 사항은 구조적 검색 AI 에이전트 도구를 참조하세요.

구조화되지 않은 데이터

구조화되지 않은 데이터에는 고정 스키마를 준수하지 않는 원시 문서, PDF, 전자 메일, 이미지 및 기타 형식이 포함됩니다. 이러한 데이터를 사용하려면 일반적으로 구문 분석, 청크 및 포함의 조합을 통해 추가 처리가 필요하며, 이를 통해 GEN AI 앱에서 효과적으로 쿼리하고 사용해야 합니다. Gen AI 앱에 구조적 데이터를 추가하는 방법에 대한 권장 사항은 구조 화되지 않은 데이터에 대한 빌드 및 추적 검색기 도구를 참조하세요.

외부 API 및 작업

일부 시나리오에서는 Gen AI 앱이 외부 시스템과 상호 작용하여 데이터를 검색하거나 작업을 수행해야 할 수 있습니다. 애플리케이션에서 도구를 호출하거나 외부 API와 상호 작용해야 하는 경우 다음을 권장합니다.

Unity 카탈로그 연결을 사용하여 API 자격 증명 관리: Unity 카탈로그 연결을 사용하여 API 자격 증명을 안전하게 제어합니다. 이 메서드는 토큰 및 비밀이 중앙에서 관리되고 액세스 제어되도록 합니다.
Databricks SDK를 통해 호출:
라이브러리의 함수 http_request 를 사용하여 databricks-sdk 외부 서비스에 HTTP 요청을 보냅니다. 이 함수는 인증에 Unity 카탈로그 연결을 활용하고 표준 HTTP 메서드를 지원합니다.
Unity 카탈로그 함수 활용하기:
Unity 카탈로그 함수에서 외부 연결을 래핑하여 사용자 지정 사전 또는 사후 처리 논리를 추가합니다.
Python 실행기 도구:
Python 함수를 사용하여 데이터 변환 또는 API 상호 작용에 대한 코드를 동적으로 실행하려면 기본 제공 Python 실행기 도구를 사용합니다.

예제:

내부 분석 애플리케이션은 외부 재무 API에서 라이브 시장 데이터를 검색합니다. 애플리케이션은 다음을 사용합니다.

API 자격 증명을 안전하게 저장하기 위한 Unity 카탈로그 외부 연결입니다.
사용자 지정 Unity 카탈로그 함수는 API 호출을 래핑하여 사전 처리(예: 데이터 정규화) 및 사후 처리(예: 오류 처리)를 추가합니다.
또한 애플리케이션은 Databricks SDK를 통해 API를 직접 호출할 수 있습니다.

구현 방법

Gen AI 앱을 개발할 때는 에이전트의 논리를 구현하기 위한 두 가지 주요 옵션인 오픈 소스 프레임워크를 활용하거나 Python 코드를 사용하여 사용자 지정 솔루션을 빌드할 수 있습니다. 다음은 각 접근 방식에 대한 장단점의 분석입니다.

프레임워크 사용(예: LangChain, LlamaIndex, CrewAI 또는 AutoGen)

장점:

기본 구성 요소: 프레임워크에는 신속한 관리, 호출 연결 및 다양한 데이터 원본과의 통합을 위한 즉시 사용 가능한 도구가 함께 제공되며, 이는 개발을 가속화할 수 있습니다.
커뮤니티 및 설명서: 커뮤니티 지원, 자습서 및 정기적인 업데이트의 혜택을 누릴 수 있습니다.
일반적인 디자인 패턴: 프레임워크는 일반적으로 일반적인 작업을 오케스트레이션하기 위한 명확한 모듈식 구조를 제공하므로 전체 에이전트 디자인을 간소화할 수 있습니다.

단점:

추상화가 추가됨: 오픈 소스 프레임워크는 특정 사용 사례에 필요하지 않을 수 있는 추상화 계층을 도입하는 경우가 많습니다.
업데이트에 대한 종속성: 버그 수정 및 기능 업데이트에 대한 프레임워크 유지 관리자에 의존할 수 있으므로 새 요구 사항에 빠르게 적응하는 기능이 느려질 수 있습니다.
잠재적 오버헤드: 추가 추상화로 인해 애플리케이션에 세분화된 제어가 필요한 경우 사용자 지정 문제가 발생할 수 있습니다.

순수 Python 사용

장점:

융통성: 순수 Python으로 개발하면 프레임워크의 디자인 결정에 제약을 받지 않고도 요구 사항에 맞게 구현을 정확하게 조정할 수 있습니다.
빠른 적응: 외부 프레임워크의 업데이트를 기다리지 않고 코드를 빠르게 조정하고 필요에 따라 변경 내용을 통합할 수 있습니다.
단순: 불필요한 추상화 계층을 방지하여 더 간결하고 성능이 좋은 솔루션을 만들 수 있습니다.

단점:

개발 노력 증가: 처음부터 빌드하려면 전용 프레임워크가 제공할 수 있는 기능을 구현하는 데 더 많은 시간과 전문 지식이 필요할 수 있습니다.
휠 재창조: 도구 체인 또는 프롬프트 관리와 같은 일반적인 기능을 직접 개발해야 할 수 있습니다.
유지 관리 책임: 모든 업데이트 및 버그 수정은 사용자의 책임이 되며 복잡한 시스템에는 어려울 수 있습니다.

궁극적으로 사용자의 결정은 프로젝트의 복잡성, 성능 요구 사항 및 필요한 제어 수준에 따라 결정되어야 합니다. 두 방법 모두 본질적으로 우수하지 않습니다. 각각은 개발 기본 설정 및 전략적 우선 순위에 따라 고유한 이점을 제공합니다.

1. 빌드

이 단계에서는 솔루션 디자인을 작업 세대 AI 애플리케이션으로 변환합니다. 모든 것을 미리 완성하는 대신, 빠르게 테스트할 수 있는 최소한의 POC(개념 증명)로 작게 시작합니다. 이렇게 하면 가능한 한 빨리 사전 프로덕션 환경에 배포하고, 실제 사용자 또는 중소기업에서 대표 쿼리를 수집하고, 실제 피드백에 따라 구체화할 수 있습니다.

준비, 빌드, 배포 단계를 보여 주는 순서도입니다.

빌드 프로세스는 다음 주요 단계를 따릅니다.

a. 데이터 준비 및 도구: 필요한 데이터에 액세스하고, 구문 분석하고, 검색할 준비가 되었는지 확인합니다. 에이전트에 필요한 Unity 카탈로그 함수 및 연결(예: 검색 API 또는 외부 API 호출)을 구현하거나 등록합니다. b. 빌드 에이전트: 간단한 POC 접근 방식부터 시작하여 핵심 논리를 오케스트레이션합니다. 다. 품질 검사: 더 많은 사용자에게 앱을 노출하기 전에 필수 기능의 유효성을 검사합니다. 다. 사전 프로덕션 에이전트 배포: POC를 사용하여 초기 피드백을 위해 사용자 및 주제 전문가를 테스트할 수 있도록 합니다. 이. 사용자 피드백 수집: 실제 사용량을 사용하여 개선 영역, 필요한 추가 데이터 또는 도구 및 다음 반복을 위한 잠재적 구체화를 식별합니다.

a. 데이터 준비 및 도구

솔루션 디자인 단계에서 앱에 필요한 데이터 원본 및 도구에 대한 초기 아이디어를 갖게 됩니다. 이 단계에서는 최소한으로 유지합니다. POC의 유효성을 검사하기에 충분한 데이터에만 집중합니다. 이렇게 하면 복잡한 파이프라인에 대한 선불 투자 없이도 신속한 반복이 보장됩니다.

데이터

데이터의 대표적인 하위 집합 식별
- 구조화된 데이터의 경우 초기 시나리오와 가장 관련된 키 테이블 또는 열을 선택합니다.
- 구조화되지 않은 데이터의 경우 대표 문서의 하위 집합만 인덱싱하는 우선 순위를 지정합니다. 필요한 경우 에이전트가 관련 텍스트 청크를 검색할 수 있도록 Mosaic AI Vector Search 와 함께 기본 청크/포함 파이프라인을 사용합니다.
데이터 액세스 설정
- 외부 API를 호출하는 데 앱이 필요한 경우 Unity 카탈로그 연결을 사용하여 자격 증명을 안전하게 저장합니다.
기본 보장 범위 유효성 검사
- 선택한 데이터 하위 집합이 테스트하려는 사용자 쿼리를 적절하게 해결하는지 확인합니다.
- 향후 반복을 위해 추가 데이터 원본 또는 복잡한 변환을 저장합니다. 현재 목표는 기본적인 타당성을 증명하고 피드백을 수집하는 것입니다.

도구

데이터 원본을 설정하면 다음 단계는 에이전트가 런타임에 호출할 도구를 구현하고 Unity 카탈로그에 등록하는 것입니다. 도구는 에이전트가 검색, 변환 또는 작업을 위해 호출할 수 있는 SQL 쿼리 또는 외부 API 호출과 같은 단일 상호 작용 함수입니다.

데이터 검색 도구

제한되고 구조화된 데이터 쿼리: 쿼리가 고정된 경우 Unity 카탈로그 SQL 함수 또는 Python UDF로 래핑합니다. 이렇게 하면 논리를 중앙 집중화하고 검색할 수 있습니다.
개방형 구조화된 데이터 쿼리: 쿼리가 더 개방형인 경우 텍스트-SQL 쿼리를 처리하도록 Genie 공간을 설정하는 것이 좋습니다.
구조화되지 않은 데이터 도우미 함수: Mosaic AI Vector Search에 저장된 구조화되지 않은 데이터의 경우 에이전트가 관련 텍스트 청크를 가져오기 위해 호출할 수 있는 구조화되지 않은 데이터 검색 도구를 만듭니 다.

API 호출 도구

외부 API 호출:API 호출은 Databricks SDK의 메서드를 사용하여 http_request.
선택적 래퍼: 데이터 정규화 또는 오류 처리와 같은 사전 또는 사후 처리 논리를 구현해야 하는 경우 Unity 카탈로그 함수에서 API 호출을 래핑합니다.

최소로 유지

필수 도구로만 시작합니다 . 단일 검색 경로 또는 제한된 API 호출 집합에 집중합니다. 반복할 때 더 추가할 수 있습니다.
대화형으로 유효성을 검사합니다. 각 도구를 에이전트 시스템에 통합하기 전에 독립적으로(예: Notebook에서) 테스트합니다.

프로토타입 도구가 준비되면 에이전트 빌드를 계속 진행합니다. 에이전트는 이러한 도구를 오케스트레이션하여 쿼리에 응답하고, 데이터를 가져오고, 필요에 따라 작업을 수행합니다.

b. 빌드 에이전트

데이터 및 도구가 배치된 후에는 사용자 쿼리와 같은 들어오는 요청에 응답하는 에이전트를 빌드할 수 있습니다. 초기 프로토타입 에이전트를 만들려면 Python 또는 AI 플레이그라운드를 사용합니다. 다음 단계를 수행하세요.

간단한 시작
- 기본 디자인 패턴을 선택합니다. POC의 경우 기본 체인(예: 단계의 고정 시퀀스) 또는 단일 도구 호출 에이전트(LLM이 하나 또는 두 개의 필수 도구를 동적으로 호출할 수 있는 경우)로 시작합니다.
  - 시나리오가 Databricks 설명서에 제공된 예제 노트북 중 하나에 부합하는 경우 해당 코드를 틀로 사용하여 조정하십시오.
- 최소 프롬프트: 이 시점에서 프롬프트를 과도하게 엔지니어링하려는 충동에 저항하십시오. 지침은 간결하고 초기 작업과 직접 관련이 있습니다.
도구 통합
- 도구 통합: 체인 디자인 패턴을 사용하는 경우 각 도구를 호출하는 단계는 하드 코딩됩니다. 도구 호출 에이전트에서는 LLM이 함수를 호출하는 방법을 알 수 있도록 스키마를 제공합니다 .
  - 격리된 도구가 예상대로 수행되고 있는지 확인한 후 에이전트 시스템에 통합하고 엔드 투 엔드를 테스트합니다.
- 가드레일: 에이전트가 외부 시스템을 수정하거나 코드를 실행할 수 있는 경우 기본 안전 검사 및 가드레일(예: 호출 횟수 제한 또는 특정 작업 제한)이 있는지 확인합니다. Unity 카탈로그 함수 내에서 구현합니다.
MLflow를 사용하여 에이전트 추적 및 로그
- 각 단계를 추적합니다 . MLflow 추적을 사용하여 단계별 입력, 출력 및 경과 시간을 캡처하여 문제를 디버그하고 성능을 측정합니다.
- 에이전트를 기록합니다.MLflow 추적 을 사용하여 에이전트의 코드 및 구성을 기록합니다.

이 단계에서 완벽은 목표가 아닙니다. 테스트 사용자 및 중소기업의 초기 피드백을 위해 배포할 수 있는 간단하고 작동하는 에이전트를 원합니다. 다음 단계는 사전 프로덕션 환경에서 사용할 수 있도록 하기 전에 빠른 품질 검사를 실행하는 것입니다.

다. 품질 검사

더 광범위한 사전 프로덕션 대상 그룹에 에이전트를 노출하기 전에 오프라인 "충분히 좋은" 품질 검사를 실행하여 엔드포인트에 배포하기 전에 주요 문제를 파악합니다. 이 단계에서는 일반적으로 크고 강력한 평가 데이터 세트가 없지만 에이전트가 소수의 샘플 쿼리에서 의도한 대로 동작하도록 빠른 패스를 수행할 수 있습니다.

Notebook에서 대화형으로 테스트
- 수동 검사: 담당자 요청을 사용하여 에이전트를 수동으로 호출합니다. 올바른 데이터를 검색하고, 도구를 올바르게 호출하고, 원하는 형식을 따르는지 주의를 기울입니다.
- MLflow 추적 정보: MLflow 추적을 사용하도록 설정한 경우, 단계별 원격 분석 데이터를 검토하십시오. 에이전트가 적절한 도구를 선택하고 오류를 정상적으로 처리하며 예기치 않은 중간 요청 또는 결과를 생성하지 않는지 확인합니다.
- 대기 시간 확인: 각 요청을 실행하는 데 걸리는 시간을 기록해 둡다. 응답 시간 또는 토큰 사용량이 너무 많은 경우 더 진행하기 전에 단계를 정리하거나 논리를 간소화해야 할 수 있습니다.
바이브 체크
- 이 작업은 Notebook 또는 AI Playground에서 수행할 수 있습니다.
- 일관성 및 정확성: 에이전트의 출력이 테스트한 쿼리에 적합합니까? 눈부신 부정확성 또는 누락된 세부 정보가 있나요?
- 엣지 케이스: 만약 몇 가지 비정형 쿼리를 시도했을 때 에이전트가 여전히 논리적으로 응답했거나, 적어도 무의미한 출력을 생성하는 대신 정중하게 답변을 거부했는지 확인해 보셨습니까?
- 프롬프트 준수: 원하는 톤 또는 서식 지정과 같은 개략적인 지침을 제공한 경우 에이전트가 다음을 수행합니까?
충분히 좋은 품질을 평가하기
- 이 시점에서 테스트 쿼리가 제한된 경우 가상 데이터를 생성하는 것이 좋습니다. 평가 집합 만들기를 참조하세요.
- 주요 문제 해결: 주요 결함을 발견한 경우(예: 에이전트가 잘못된 도구를 반복적으로 호출하거나 넌센스를 출력하는 경우) 이러한 문제를 해결한 후 더 많은 대상에게 노출합니다. 일반적인 품질 문제 및 해결 방법을 참조하세요.
- 실행 가능성을 결정합니다. 에이전트가 작은 쿼리 집합에 대한 사용 가능성 및 정확성의 기본 막대를 충족하는 경우 계속 진행할 수 있습니다. 그렇지 않은 경우 프롬프트를 구체화하고, 도구 또는 데이터 문제를 수정하고, 다시 테스트합니다.
다음 단계 계획
- 개선 사항 추적: 연기하기로 결정한 단점을 문서화합니다. 사전 프로덕션에서 실제 피드백을 수집한 후에는 이러한 피드백을 다시 확인할 수 있습니다.

제한된 출시를 위해 모든 것이 실행 가능한 것으로 보이는 경우 사전 프로덕션에 에이전트를 배포할 준비가 된 것입니다. 특히 더 많은 실제 데이터, SME 피드백 및 구조적 평가 집합이 있는 후 이후 단계에서 철저한 평가 프로세스가 수행됩니다. 지금은 에이전트가 핵심 기능을 안정적으로 보여 주는 데 집중합니다.

다. 사전 프로덕션 에이전트 배포

에이전트가 기준 품질 임계값을 충족하면 다음 단계는 사용자가 앱을 쿼리하고 피드백을 수집하여 개발을 안내하는 방법을 이해할 수 있도록 사전 프로덕션 환경에서 호스트하는 것입니다. 이 환경은 POC 단계에서 개발 환경이 될 수 있습니다. 주요 요구 사항은 내부 테스터 또는 도메인 전문가를 선택할 수 있는 환경에 액세스할 수 있다는 것입니다.

에이전트 배포
- 에이전트 로그 및 등록: 먼저 에이전트를 MLflow 모델로 기록하고 Unity 카탈로그에 등록합니다 .
- 에이전트 프레임워크를 사용하여 배포: 에이전트 프레임워크를 사용하여 등록된 에이전트를 가져와서 모델 서비스 엔드포인트로 배포합니다 .
유추 테이블
- 에이전트 프레임워크는 각 서비스 엔드포인트에 대한 Unity 카탈로그 의 유추 테이블에 메타데이터와 함께 요청, 응답 및 추적을 자동으로 저장합니다.
보안 및 구성
- 액세스 제어:테스트 그룹(SME, 전원 사용자)에 대한 엔드포인트 액세스를 제한합니다. 이렇게 하면 제어된 사용량이 보장되고 예기치 않은 데이터 노출이 방지됩니다.
- 인증: 필요한 비밀, API 토큰 또는 데이터베이스 연결이 제대로 구성되었는지 확인합니다.

이제 실제 쿼리에 대한 피드백을 수집하기 위한 제어된 환경이 있습니다. 에이전트와 빠르게 상호 작용할 수 있는 방법 중 하나는 새로 만든 모델 서비스 엔드포인트를 선택하고 에이전트를 쿼리할 수 있는 AI Playground입니다.

이. 사용자 피드백 수집

사전 프로덕션 환경에 에이전트를 배포한 후 다음 단계는 실제 사용자 및 중소기업으로부터 피드백을 수집하여 격차를 파악하고, 부정확성을 발견하고, 에이전트를 추가로 구체화하는 것입니다.

검토 앱 사용
- 에이전트 프레임워크를 사용하여 에이전트를 배포하면 간단한 채팅 스타일 검토 앱 이 만들어집니다. 테스터가 질문을 하고 에이전트의 응답을 즉시 평가할 수 있는 사용자 친화적인 인터페이스를 제공합니다.
- 모든 요청, 응답 및 사용자 피드백(엄지 손가락 위로/아래로, 작성된 메모)은 유추 테이블에 자동으로 기록되므로 나중에 쉽게 분석할 수 있습니다.
모니터링 UI를 사용하여 로그 검사
- 모니터링 UI에서 upvotes/downvotes 또는 텍스트 피드백을 추적하여 테스터들이 어떤 응답을 특히 유용하게 느꼈는지(또는 유용하지 않았는지) 확인합니다.
도메인 전문가 참여
- 중소기업이 일반적이고 비정상적인 시나리오를 실행하도록 장려합니다. 도메인 지식은 정책 잘못 해석 또는 누락된 데이터와 같은 미묘한 오류를 노출하는 데 도움이 됩니다.
- 사소한 프롬프트 조정부터 더 큰 데이터 파이프라인 리팩터에 이르기까지 문제의 백로그를 유지합니다. 계속 진행하기 전에 우선 순위를 지정할 수정 사항을 결정합니다.
새 평가 데이터 큐레이팅
- 주목할 만한 상호 작용 또는 문제가 있는 상호 작용을 테스트 사례로 변환합니다. 시간이 지남에 따라 이러한 데이터 세트는 보다 강력한 평가 데이터 세트의 기초가 됩니다.
- 가능하면 이러한 사례에 정확하거나 예상된 답변을 추가합니다. 이렇게 하면 후속 평가 주기에서 품질을 측정하는 데 도움이 됩니다.
피드백에 따라 반복
- 작은 프롬프트 변경 또는 새로운 가드레일과 같은 빠른 수정을 적용하여 즉각적인 문제를 해결합니다.
- 고급 다단계 논리 또는 새 데이터 원본 요구와 같은 더 복잡한 문제의 경우 주요 아키텍처 변경에 투자하기 전에 충분한 증거를 수집합니다.

이 사전 프로덕션 단계는 검토 앱, 추론 테이블 로그 및 SME 인사이트의 피드백을 활용하여 주요 결점을 파악하고 에이전트를 반복적으로 개선하는 데 도움이 됩니다. 이 단계에서 수집된 실제 상호 작용은 구조적 평가 집합을 빌드하기 위한 토대를 만들어 임시 개선에서 품질 측정에 대한 보다 체계적인 접근 방식으로 전환할 수 있도록 합니다. 되풀이 문제가 해결되고 성능이 안정화되면 강력한 평가가 적용된 프로덕션 배포에 대해 잘 준비됩니다.

2. 평가 및 반복

사전 프로덕션 환경에서 Gen AI 앱을 테스트한 후 다음 단계는 품질을 체계적으로 측정, 진단 및 구체화하는 것입니다. 이 "평가 및 반복" 단계는 원시 피드백 및 로그를 구조화된 평가 집합으로 변환하여 개선을 반복적으로 테스트하고 앱이 정확도, 관련성 및 안전에 필요한 표준을 충족하는지 확인할 수 있도록 합니다.

이 단계에는 다음 단계가 포함됩니다.

로그에서 실제 쿼리 수집: 유추 테이블에서 높은 값 또는 문제가 있는 상호 작용을 테스트 사례로 변환합니다.
전문가 레이블 추가: 가능한 경우 정확성, 근거 및 기타 품질 차원을 보다 객관적으로 측정할 수 있도록 이러한 사례에 기본 사실이나 스타일 및 정책 지침을 첨부합니다.
에이전트 평가 활용: 기본 제공 LLM 심사위원 또는 사용자 지정 검사를 사용하여 앱 품질을 정량화합니다.
반복: 에이전트의 논리, 데이터 파이프라인 또는 프롬프트를 구체화하여 품질을 향상시킵니다. 평가를 다시 실행하여 주요 문제를 해결했는지 확인합니다.

이러한 기능은 Gen AI 앱이 Databricks 외부에서 실행되는 경우에도 작동합니다. MLflow 추적을 사용하여 코드를 계측하면 모든 환경에서 추적을 캡처하고 Databricks Data Intelligence 플랫폼에서 통합하여 일관된 평가 및 모니터링을 수행할 수 있습니다. 새로운 쿼리, 피드백 및 SME 인사이트를 계속 통합하면 평가 데이터 세트는 지속적인 개선 주기를 뒷받침하는 살아있는 리소스가 되어 Gen AI 앱이 견고하고 안정적이며 비즈니스 목표에 맞게 유지되도록 합니다.

준비, 빌드, 배포 및 수정 단계를 보여 주는 순서도입니다.

가. 에이전트 평가

에이전트가 사전 프로덕션 환경에서 실행된 후 다음 단계는 임시 바이브 검사를 넘어 성능을 체계적으로 측정하는 것입니다. Mosaic AI 에이전트 평가를 사용하면 평가 집합을 만들고, 기본 제공 또는 사용자 지정 LLM 심사위원으로 품질 검사를 실행하고, 문제 영역을 신속하게 반복할 수 있습니다.

오프라인 및 온라인 평가

Gen AI 애플리케이션을 평가할 때는 오프라인 평가와 온라인 평가의 두 가지 주요 방법이 있습니다. 개발 주기의 이 단계는 라이브 사용자 상호 작용 외부의 체계적인 평가를 의미하는 오프라인 평가에 중점을 둡니다. 온라인 평가는 나중에 프로덕션에서 에이전트 모니터링에 대해 논의할 때 설명합니다.

팀은 개발자 워크플로에서 너무 오랫동안 "바이브 테스트"에 너무 많이 의존 하여 비공식적으로 소수의 쿼리를 시도하고 응답이 합리적인지 주관적으로 판단합니다. 이는 시작점을 제공하지만 프로덕션 품질 애플리케이션을 빌드하는 데 필요한 엄격함과 적용 범위가 부족합니다.

반면에 적절한 오프라인 평가 프로세스는 다음을 수행합니다.

더 넓은 배포 전에 품질 기준을 설정하여 개선 대상에 대한 명확한 메트릭을 만듭니다.
예상되는 사용 사례만 테스트하는 제한을 넘어 주의가 필요한 특정 약점을 식별합니다.
버전 간에 성능을 자동으로 비교하여 앱을 구체화할 때 품질 회귀를 감지합니다.
이해 관계자의 개선을 보여 주는 양적 메트릭을 제공합니다.
사용자가 하기 전에 에지 사례 및 잠재적인 오류 모드를 검색하는 데 도움이 됩니다.
성능이 저조한 에이전트를 프로덕션에 배포할 위험을 줄입니다.

오프라인 평가에 시간을 투자하면 장기적으로 상당한 배당금을 지급하므로 일관된 고품질 응답을 제공하는 데 도움이 됩니다.

평가 집합 만들기

평가 집합은 Gen AI 앱의 성능을 측정하기 위한 기초 역할을 합니다. 기존 소프트웨어 개발의 테스트 도구 모음과 마찬가지로 이 대표적인 쿼리 및 예상 응답 컬렉션은 품질 벤치마크 및 회귀 테스트 데이터 세트가 됩니다.

준비, 빌드, 배포 및 수정 단계를 평가 집합과 함께 보여주는 순서도입니다.

다음과 같은 몇 가지 보완적인 방법을 통해 평가 집합을 빌드할 수 있습니다.

유추 테이블 로그를 평가 예제로 변환

가장 중요한 평가 데이터는 실제 사용량에서 직접 제공됩니다. 사전 프로덕션 배포는 요청, 에이전트 응답, 도구 호출 및 검색된 컨텍스트를 포함하는 유추 테이블 로그를 생성했습니다.

이러한 로그를 평가 집합으로 변환하면 다음과 같은 몇 가지 이점이 있습니다.
- 실제 적용 범위: 예측할 수 없는 사용자 동작이 포함됩니다.
- 문제 중심: 특히 부정적인 피드백 또는 느린 응답에 대해 필터링할 수 있습니다.
- 대표 배포: 서로 다른 쿼리 형식의 실제 빈도가 캡처됩니다.
가상 평가 데이터 생성

큐레이팅된 사용자 쿼리 집합이 없는 경우 가상 평가 데이터 세트를 자동으로 생성할 수 있습니다. 이 "시작 집합" 쿼리는 에이전트를 빠르게 평가하는 데 도움이 됩니다.
- 일관되며 정확한 답변을 반환합니다.
- 올바른 형식으로 응답합니다.
- 구조, 톤 및 정책 지침을 존중합니다.
- 컨텍스트(RAG의 경우)를 올바르게 검색합니다.
합성 데이터는 일반적으로 완벽하지 않습니다. 임시 디딤돌로 생각하십시오. 다음을 수행하고 싶을 것입니다.
- 중소기업 또는 도메인 전문가가 관련없거나 반복적인 쿼리를 검토하고 정리합니다.
- 나중에 실제 사용 로그로 바꾸거나 보강합니다.
수동으로 쿼리 큐레이팅

가상 데이터에 의존하지 않거나 아직 유추 로그가 없는 경우 10~15개의 실제 또는 대표 쿼리를 식별하고 이러한 쿼리에서 평가 집합을 만듭니다. 대표적인 쿼리는 사용자 인터뷰 또는 개발자 브레인스토밍에서 나올 수 있습니다. 짧고 큐레이팅된 목록조차도 에이전트의 응답에 눈부신 결함을 노출할 수 있습니다.

이러한 접근 방식은 상호 배타적이지는 않지만 보완적입니다. 효과적인 평가 집합은 시간이 지남에 따라 진화하며 일반적으로 다음을 포함하여 여러 원본의 예제를 결합합니다.

핵심 기능을 테스트하기 위해 수동으로 큐레이팅된 예제부터 시작합니다.
필요에 따라 실제 사용자 데이터를 사용하기 전에 가상 데이터를 추가하여 범위를 넓힐 수 있습니다.
실제 로그를 사용할 수 있게 되면 점차 통합합니다.
변경된 사용 패턴을 반영하는 새 예제를 사용하여 지속적으로 새로 고칩니다.

평가 쿼리에 대한 모범 사례

평가 집합을 만들 때 다음과 같은 다양한 쿼리 형식을 의도적으로 포함합니다.

예상된 사용 패턴과 예기치 않은 사용 패턴(예: 매우 길거나 짧은 요청)
잠재적인 오용 시도 또는 프롬프트 삽입 공격(예: 시스템 프롬프트 표시 시도).
여러 추론 단계 또는 도구 호출이 필요한 복잡한 쿼리입니다.
최소 또는 모호한 정보(예: 맞춤법 오류 또는 모호한 쿼리)가 있는 에지 사례입니다.
다양한 사용자 기술 수준 및 배경을 나타내는 예제입니다.
응답에서 잠재적 편견을 테스트하는 쿼리(예: "회사 A와 B 회사 비교").

평가 집합은 애플리케이션과 함께 성장하고 발전해야 합니다. 새 오류 모드 또는 사용자 동작을 발견할 때 에이전트가 해당 영역에서 계속 개선되도록 대표적인 예제를 추가합니다.

평가 조건 추가

각 평가 예제에는 품질을 평가하는 기준이 있어야 합니다. 이러한 기준은 에이전트의 응답을 측정하여 여러 품질 차원에서 객관적인 평가를 가능하게 하는 표준 역할을 합니다.

근거 진리 사실 또는 참조 답변

사실 정확도를 평가할 때는 예상된 팩트 또는 참조 답변이라는 두 가지 주요 방법이 있습니다. 각 기능은 평가 전략에서 다른 용도로 사용됩니다.

예상 팩트 사용(권장)

expected_facts 방법은 올바른 응답에 표시되어야 하는 주요 사실을 나열하는 것입니다. 예를 보시려면 request, response, guidelines, 및 expected_facts이 포함된 샘플 평가 집합을 참조하세요.

이 방법은 다음과 같은 상당한 이점을 제공합니다.

응답에서 팩트를 표현하는 방법을 유연하게 사용할 수 있습니다.
중소기업이 더 쉽게 근거를 제공할 수 있도록 합니다.
핵심 정보가 있는지 확인하면서 다양한 응답 스타일을 수용합니다.
모델 버전 또는 매개 변수 설정에서 보다 신뢰할 수 있는 평가를 사용하도록 설정합니다.

기본 제공 정확성 판사는 구문, 주문 또는 추가 콘텐츠에 관계없이 에이전트의 응답이 이러한 필수 사실을 통합하는지 여부를 확인합니다.

예상 응답 사용(대체)

또는 전체 참조 답변을 제공할 수 있습니다. 이 방법은 다음과 같은 상황에서 가장 잘 작동합니다.

전문가에 의해 만들어진 골드 표준 답변이 있습니다.
응답의 정확한 표현이나 구조가 중요합니다.
높은 규제 컨텍스트에서 응답을 평가하고 있습니다.

Databricks는 일반적으로 정확도를 유지하면서 더 많은 유연성을 제공하기 때문에 expected_facts보다 expected_response를 사용하는 것이 좋습니다.

스타일, 톤 또는 정책 준수에 대한 지침

사실 정확도 외에도 응답이 특정 스타일, 톤 또는 정책 요구 사항을 준수하는지 여부를 평가해야 할 수 있습니다.

지침만

주요 관심사가 사실 정확도가 아닌 스타일 또는 정책 요구 사항을 적용하는 경우 예상된 사실 없이 지침을 제공할 수 있습니다.

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

LLM 판사는 이러한 자연어 지침을 해석하고 응답이 이를 준수하는지 여부를 평가합니다. 이는 특히 톤, 서식 지정 및 조직 정책 준수와 같은 주관적인 품질 차원에 적합합니다.

스타일과 톤을 평가하는 LLM 판정 UI.

기준 진리와 지침의 결합

포괄적인 평가를 위해 사실 정확도 검사를 스타일 지침과 결합할 수 있습니다. request, response, guidelines, 및 expected_facts로 구성된 샘플 평가 집합을 참조하세요. 이 방법을 사용하면 응답이 실제로 정확하고 조직의 통신 표준을 준수할 수 있습니다.

미리 캡처된 응답 사용

개발 또는 테스트에서 요청-응답 쌍을 이미 캡처한 경우 에이전트를 다시 호출하지 않고 직접 평가할 수 있습니다. 이 기능은 다음과 같은 경우에 유용합니다.

에이전트 동작에서 기존 패턴을 분석합니다.
이전 버전과 성능을 벤치마킹하는 것.
응답을 다시 생성하지 않음으로써 시간과 비용을 절감합니다.
Databricks 외부에서 제공되는 에이전트를 평가합니다.

평가 DataFrame에서 관련 열을 제공하는 방법에 대한 자세한 내용은 예제: 이전에 생성된 출력을 에이전트 평가에 전달하는 방법을 참조하세요. Mosaic AI 에이전트 평가는 에이전트를 다시 호출하는 대신 이러한 미리 캡처된 값을 사용하는 동시에 동일한 품질 검사 및 메트릭을 적용합니다.

평가 기준에 대한 모범 사례

평가 조건을 정의하는 경우:

구체적이고 객관적인 정보: 다른 평가자가 유사하게 해석하는 명확하고 측정 가능한 조건을 정의합니다.
- 관심 있는 품질 기준을 측정하기 위해 사용자 지정 메트릭을 추가하는 것이 좋습니다.
사용자 값에 집중: 사용자에게 가장 중요한 항목에 맞는 조건의 우선 순위를 지정합니다.
간단한 시작: 핵심 조건 집합으로 시작하고 품질 요구 사항에 대한 이해가 커짐에 따라 확장합니다.
잔액 적용 범위: 다양한 품질 측면(예: 사실 정확도, 스타일 및 안전성)을 다루는 조건을 포함합니다.
피드백에 따라 반복합니다. 사용자 피드백 및 진화하는 요구 사항에 따라 조건을 구체화합니다.

고품질 평가 데이터 세트를 빌드하는 방법에 대한 자세한 내용은 평가 집합을 개발하기 위한 모범 사례를 참조하세요.

평가 실행

이제 쿼리 및 조건을 사용하여 평가 집합을 준비했으므로 다음을 사용하여 mlflow.evaluate()평가를 실행할 수 있습니다. 이 함수는 에이전트 호출부터 결과 분석까지 전체 평가 프로세스를 처리합니다.

기본 평가 워크플로

기본 평가를 실행하려면 몇 줄의 코드만 필요합니다. 자세한 내용은 평가 실행을 참조하세요.

평가가 트리거되는 경우:

평가 집합 mlflow.evaluate() 의 각 행에 대해 다음을 수행합니다.
- 쿼리를 사용하여 에이전트를 호출합니다(응답을 아직 제공하지 않은 경우).
- 기본 제공 LLM 심사위원을 적용하여 품질 차원을 평가합니다.
- 토큰 사용량 및 대기 시간과 같은 운영 메트릭을 계산합니다.
- 각 평가에 대한 자세한 근거를 기록합니다.
결과는 MLflow에 자동으로 기록되어 다음을 만듭니다.
- 각 행에 대한 품질 평가.
- 모든 예제에서 집계된 메트릭입니다.
- 디버깅 및 분석을 위한 자세한 로그입니다.

판사 평가를 보여주는 LLM 판사 UI.

평가 사용자 지정

추가 매개 변수를 사용하여 특정 요구 사항에 맞게 평가를 조정할 수 있습니다. 매개 evaluator_config 변수를 사용하면 다음을 수행할 수 있습니다.

내장된 심사위원을 선택하십시오.
모든 예제에 적용되는 전역 지침을 설정합니다.
심사위원에 대한 임계값을 구성합니다.
판사 평가를 안내하는 몇 가지 예제를 제공합니다.

자세한 내용 및 예제는 예제를 참조하세요.

에이전트를 Databricks 외부에서 평가

에이전트 평가의 강력한 기능 중 하나는 Databricks뿐만 아니라 어디서나 배포된 Gen AI 앱을 평가하는 기능입니다.

어떤 심사위원이 적용되는지

기본적으로 에이전트 평가는 평가 집합에서 사용할 수 있는 데이터에 따라 적절한 LLM 심사위원 을 자동으로 선택합니다. 품질을 평가하는 방법에 대한 자세한 내용은 LLM 심사위원이 품질을 평가하는 방법을 참조하세요.

평가 결과 분석

평가를 실행한 후 MLflow UI는 앱의 성능을 이해하기 위한 시각화 및 인사이트를 제공합니다. 이 분석은 패턴을 식별하고, 문제를 진단하고, 개선의 우선 순위를 지정하는 데 도움이 됩니다.

평가 결과 탐색

실행 mlflow.evaluate(), 후 MLflow UI를 열면 상호 연결된 여러 보기가 표시됩니다. MLflow UI에서 이러한 결과를 탐색하는 방법에 대한 자세한 내용은 MLflow UI를 사용하여 출력 검토를 참조하세요.

실패 패턴을 해석하는 방법에 대한 지침은 b. 에이전트 및 도구 개선을 참조하세요.

사용자 지정 AI 판단 및 메트릭

기본 제공 심사위원은 많은 일반적인 검사(예: 정확성, 스타일, 정책 및 안전)를 다루지만 앱 성능의 도메인별 측면을 평가해야 할 수 있습니다. 사용자 지정 심사위원 및 메트릭을 사용하면 고유한 품질 요구 사항을 해결하기 위해 평가 기능을 확장할 수 있습니다.

사용자 지정 LLM 심사위원

프롬프트에서 사용자 지정 LLM 판사를 만드는 방법에 대한 자세한 내용은 프 롬프트에서 AI 심사위원 만들기를 참조하세요.

사용자 지정 심사위원은 다음과 같은 인간과 같은 판단을 통해 이익을 얻는 주관적이거나 미묘한 품질 차원을 평가하는 데 탁월합니다.

도메인별 규정 준수(법률, 의료, 재무).
브랜드 음성 및 커뮤니케이션 스타일.
문화적 감수성과 적합성.
복잡한 추론 품질.
특수 쓰기 규칙입니다.

판사의 출력은 기본 제공 심사위원과 함께 MLflow UI에 표시되며 평가를 설명하는 동일한 자세한 근거가 있습니다.

사용자 지정 메트릭

프로그램적으로 결정적 평가를 수행하기 위해, 데코레이터 @metric를 사용하여 사용자 지정 메트릭을 만들 수 있습니다. 데코레이터를 참조하십시오@metric.

사용자 지정 메트릭은 다음 작업에 적합합니다.

형식 유효성 검사 및 스키마 준수와 같은 기술 요구 사항을 확인합니다.
특정 콘텐츠의 존재 여부 또는 부재를 확인합니다.
응답 길이 또는 복잡성 점수와 같은 양적 측정 수행
비즈니스별 유효성 검사 규칙 구현
외부 유효성 검사 시스템과 통합

b. 에이전트 및 도구 개선

평가를 실행하고 품질 문제를 식별한 후 다음 단계는 성능을 향상시키기 위해 이러한 문제를 체계적으로 해결하는 것입니다. 평가 결과는 에이전트가 실패하는 위치와 방법에 대한 중요한 인사이트를 제공하므로 임의 조정이 아닌 대상을 개선할 수 있습니다.

일반적인 품질 문제 및 해결 방법

평가 결과에 따르면, LLM 심사위원들의 평가는 귀하의 에이전트 시스템에 있는 특정 유형의 실패를 지적합니다. 이 섹션에서는 이러한 일반적인 오류 패턴 및 해당 솔루션을 살펴봅니다. LLM 판사 출력을 해석하는 방법에 대한 자세한 내용은 AI 판사 출력을 참조하세요.

품질 반복 모범 사례

개선 사항을 반복할 때 엄격한 설명서를 유지 관리합니다. 다음은 그 예입니다.

변경 내용을 버전 지정하기
- MLflow 추적을 사용하여 각 중요한 반복을 기록합니다.
- 중앙 구성 파일 내에 프롬프트, 구성 및 키 매개 변수를 저장합니다. 에이전트가 이를 기록하도록 하십시오.
- 새로 배포된 각 에이전트에 대해 변경 내용과 이유를 자세히 설명하는 리포지토리의 변경 로그 를 유지 관리합니다.
작동된 작업과 작동하지 않은 작업 모두 문서화
- 성공 및 실패한 방법을 모두 문서화합니다.
- 각 변경 내용이 메트릭에 미치는 특정 영향을 확인합니다. 에이전트 평가 MLflow 실행에 다시 연결합니다.
관련자와 일치
- 검토 앱을 사용하여 중소기업의 향상된 기능의 유효성을 검사합니다.
  - 검토자 지침을 사용하여 검토자에게 변경 내용을 전달합니다.
- 서로 다른 버전의 에이전트를 나란히 비교하려면 여러 에이전트 엔드포인트를 만들고 AI Playground에서 모델을 사용하는 것이 좋습니다. 이를 통해 사용자는 엔드포인트를 분리하기 위해 동일한 요청을 보내고 응답 및 추적을 나란히 검사할 수 있습니다.

3. 프로덕션

앱을 반복적으로 평가하고 개선한 후에는 요구 사항을 충족하고 더 광범위한 사용을 위한 준비가 된 품질 수준에 도달했습니다. 프로덕션 단계에는 프로덕션 환경에 구체화된 에이전트를 배포하고 지속적인 모니터링을 구현하여 시간이 지남에 따라 품질을 유지하는 작업이 포함됩니다.

프로덕션 단계에는 다음이 포함됩니다.

프로덕션에 에이전트 배포: 적절한 보안, 크기 조정 및 인증 설정을 사용하여 프로덕션 준비 엔드포인트를 설정합니다.
프로덕션에서 에이전트 모니터링: 에이전트가 실제 사용에서 높은 품질과 안정성을 유지할 수 있도록 지속적인 품질 평가, 성능 추적 및 경고를 설정합니다.

이렇게 하면 모니터링 인사이트가 더 개선되어 테스트, 배포 및 모니터링을 계속할 수 있는 지속적인 피드백 루프가 만들어집니다. 이 접근 방식을 통해 앱은 수명 주기 내내 발전하는 비즈니스 요구 사항에 맞게 고품질, 규정 준수 및 조정 상태를 유지할 수 있습니다.

모니터링 및 로그를 포함한 전체 세대 AI 개발 워크플로를 보여 주는 순서도입니다.

a. 프로덕션 환경에 에이전트 배포

철저한 평가 및 반복적인 개선을 완료한 후에는 프로덕션 환경에 에이전트를 배포할 준비가 된 것입니다. [Mosaic AI 에이전트 프레임워크](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework)는 많은 배포 문제를 자동으로 처리하여 이 프로세스를 간소화합니다.

배포 프로세스

프로덕션에 에이전트를 배포하려면 다음 단계를 수행합니다.

Unity 카탈로그에서 에이전트를 MLflow 모델로 로그 및 등록합니다.
에이전트 프레임워크를 사용하여 에이전트를 배포합니다.
에이전트에서 액세스해야 하는 종속 리소스에 대한 인증을 구성합니다.
배포를 테스트하여 프로덕션 환경에서 기능을 확인합니다.
- 엔드포인트를 제공하는 모델이 준비되면 AI Playground에서 에이전트와 상호 작용하여 기능을 테스트하고 확인할 수 있습니다.

자세한 구현 단계는 생성 AI 애플리케이션에 대한 에이전트 배포를 참조하세요.

프로덕션 배포 고려 사항

프로덕션으로 전환할 때 다음 주요 고려 사항을 염두에 두어야 합니다.

성능 및 크기 조정

예상 사용 패턴에 따라 비용과 성능의 균형을 조정합니다.
간헐적으로 사용되는 에이전트 에 대해 크기 조정을 0 으로 설정하여 비용을 절감하는 것이 좋습니다.
애플리케이션의 사용자 환경 요구 사항에 따라 대기 시간 요구 사항을 이해합니다.

보안 및 거버넌스

모든 에이전트 구성 요소에 대한 Unity 카탈로그 수준에서 적절한 액세스 제어를 확인합니다.
가능한 경우 Databricks 리소스에 대해 내장된 인증 패스스루를 사용합니다.
외부 API 또는 데이터 원본에 대한 적절한 자격 증명 관리를 구성합니다.

통합 접근 방식

애플리케이션이 에이전트와 상호 작용하는 방법을 결정합니다(예: API 또는 포함된 인터페이스 사용).
애플리케이션에서 에이전트 응답을 처리하고 표시하는 방법을 고려합니다.
- 클라이언트 애플리케이션에 추가 컨텍스트(예: 원본 문서 참조 또는 신뢰도 점수)가 필요한 경우 응답에 이 메타데이터를 포함하도록 에이전트를 디자인합니다(예: 사용자 지정 출력 사용).
에이전트를 사용할 수 없는 경우에 대한 오류 처리 및 대체 메커니즘을 계획합니다.

피드백 컬렉션

초기 출시 중에 이해 관계자 피드백을 위해 검토 앱을 활용합니다.
애플리케이션 인터페이스에서 직접 사용자 피드백을 수집하는 메커니즘을 디자인합니다.
- 검토 앱에서 피드백을 수집하기 위해 만든 피드백 엔드포인트는 외부 애플리케이션에서 에이전트에 대한 피드백을 제공하는 데 사용할 수도 있습니다. 배포된 에이전트에 대한 피드백 제공을 참조하세요.
피드백 데이터가 평가 및 개선 프로세스로 흐르는지 확인합니다.

b. 프로덕션에서 에이전트 모니터링

에이전트가 프로덕션에 배포된 후에는 성능, 품질 및 사용 패턴을 지속적으로 모니터링해야 합니다. 기능이 결정적인 기존 소프트웨어와 달리 Gen AI 앱은 실제 입력이 발생할 때 품질 드리프트 또는 예기치 않은 동작을 나타낼 수 있습니다. 효과적인 모니터링을 사용하면 문제를 조기에 감지하고, 사용 패턴을 이해하고, 애플리케이션의 품질을 지속적으로 개선할 수 있습니다.

에이전트 모니터링 설정

Mosaic AI는 사용자 지정 모니터링 인프라를 빌드하지 않고도 에이전트의 성능을 추적할 수 있는 기본 제공 모니터링 기능을 제공합니다.

배포한 에이전트에 대한 모니터를 생성합니다.
트래픽 볼륨 및 모니터링 요구 사항에 따라 샘플링 속도 및 빈도를 구성합니다.
샘플링된 요청에서 자동으로 평가할 품질 메트릭을 선택합니다.

핵심 모니터링 지표

일반적으로 효과적인 모니터링은 세 가지 중요한 차원을 포함해야 합니다.

운영 메트릭
- 요청 볼륨 및 패턴.
- 응답 대기 시간.
- 오류 비율 및 유형입니다.
- 토큰 사용량 및 비용.
품질 메트릭
- 사용자 쿼리와 관련이 있습니다.
- 검색된 컨텍스트에서의 기초성.
- 안전 및 지침 준수.
- 전체 품질 합격 비율입니다.
사용자 피드백
- 명시적 피드백(엄지 손가락 위로/아래로).
- 암시적 신호(후속 질문, 중단된 대화).
- 지원 채널에 보고된 문제입니다.

모니터링 UI 사용

모니터링 UI는 두 개의 탭을 통해 이러한 차원에 걸쳐 시각화된 인사이트를 제공합니다.

차트 탭: 요청 볼륨, 품질 메트릭, 대기 시간 및 시간에 따른 오류의 추세를 봅니다.
로그 탭: 평가 결과를 포함하여 개별 요청 및 응답을 검사합니다.

필터링 기능을 사용하면 사용자가 특정 쿼리를 검색하거나 평가 결과를 필터링할 수 있습니다. 자세한 내용은 생성 AI에 대한 Lakehouse 모니터링이란? (MLflow 2).

대시보드 및 경고 만들기

포괄적인 모니터링의 경우:

평가된 추적 테이블에 저장된 모니터링 데이터를 사용하여 사용자 지정 대시보드를 빌드합니다.
중요한 품질 또는 운영 임계값에 대한 경고를 설정합니다.
주요 관련자와 정기적인 품질 검토를 예약합니다.

지속적인 개선 주기

모니터링은 개선 프로세스에 다시 공급될 때 가장 중요합니다.

메트릭 및 사용자 피드백을 모니터링하여 문제를 식별합니다.
문제가 있는 예제를 평가 집합으로 내보냅니다.
MLflow 추적 분석 및 LLM 판단 결과를 사용하여 근본 원인을 진단합니다(일반적인 품질 문제 및 해결 방법에서 설명).
확장된 평가 집합에 대한 개선 사항을 개발하고 테스트합니다.
업데이트를 배포하고 영향을 모니터링합니다 .

이 반복적이고 닫힌 루프 접근 방식을 사용하면 에이전트가 실제 사용 패턴에 따라 지속적으로 개선되고 변화하는 요구 사항 및 사용자 동작에 적응하면서 고품질을 유지할 수 있습니다. 에이전트 모니터링을 사용하면 에이전트가 프로덕션 환경에서 어떻게 수행되는지 파악할 수 있으므로 문제를 사전에 해결하고 품질 및 성능을 최적화할 수 있습니다.