Databricks에서 도메인 전문가가 안내하는 자가 최적화 축구 챗봇

일반 LLM 심사자와 정적 프롬프트는 도메인별 뉘앙스를 포착하지 못합니다. '좋은' 미식축구 수비 분석을 결정하려면 커버리지 체계, 포메이션 경향, 상황적 맥락과 같은 깊은 미식축구 지식이 필요합니다. 범용 평가자는 이러한 점을 놓칩니다. 이는 법률 검토, 의료 분류, 재무 실사 또는 전문가의 판단이 중요한 모든 분야에서도 마찬가지입니다.

이 게시물에서는 Databricks Agent Framework를 기반으로 구축된 자체 최적화 에이전트 를 위한 아키텍처를 자세히 살펴봅니다. 이 아키텍처에서는 기업별 인간 전문 지식을 활용하여 MLflow를 통해 AI 품질을 지속적으로 개선하고 개발자가 전체 경험을 제어합니다. 이 게시물에서는 미식축구 수비 코디네이터(DC) 어시스턴트를 실행 예시로 사용합니다. 이 어시스턴트는 '"11명의 선수 구성에서 3rd-and-6 상황에 누가 공을 받나요?"' 또는 '"전반/후반 종료 2분 전에 상대팀은 무엇을 하나요?"'와 같은 질문에 답할 수 있는 도구 호출 에이전트입니다. 다음 예시는 이 에이전트가 Databricks 앱을 통해 사용자와 상호 작용하는 것을 보여줍니다.

에이전트에서 자체 최적화 시스템으로

솔루션은 에이전트 구축과 전문가 피드백을 통한 지속적인 최적화라는 두 단계로 구성됩니다.

빌드

• 데이터 수집: 도메인 데이터(플레이 바이 플레이, 참여, 로스터)를 Unity Catalog의 관리형 Delta 테이블에 로드합니다.
  • 이 에이전트의 데이터로 nflreadpy 에서 2년간(2023-2024년)의 미식축구 참여 및 플레이 바이 플레이 데이터를 수집했습니다.
• 도구 생성: SQL 함수를 에이전트가 호출할 수 있는 Unity Catalog 도구로 정의하여 추출된 데이터를 활용합니다.
• 에이전트 정의 및 배포: 도구를 ResponsesAgent에 연결하고, 기준 시스템 프롬프트를 Prompt Registry에 등록한 다음, Model Serving에 배포합니다.
• 초기 평가: LLM 심사위원을 사용하여 자동화된 평가를 실행하고 사용자 지정 심사위원의 기준 버전을 사용하여 로그를 기록합니다.

최적화

• 전문가 피드백 캡처: SME(주제 전문가)가 에이전트 출력을 검토하고 MLflow 레이블 지정 세션을 통해 구조화된 피드백을 제공합니다.
• 심사자 정렬: MLflow align() 함수를 사용하여 기준 LLM 심사자를 보정하여 SME 선호도와 일치시키고, 이 도메인에서 '좋은' 것이 무엇인지 학습시킵니다.
• 프롬프트 최적화: MLflow의 optimize_prompts() 는 정렬된 judge가 안내하는 GEPA 옵티마이저를 사용하여 원래 시스템 프롬프트를 반복적으로 개선합니다.
• 반복: 각 MLflow 레이블링 세션은 심사자를 개선하는 데 사용되며, 이는 결과적으로 시스템 프롬프트를 최적화하는 데 사용됩니다. 이 전체 프로세스를 자동화하여 성능 벤치마크를 초과하는 새로운 프롬프트 버전을 자동으로 승격시키거나, 관찰된 실패 모드를 기반으로 더 많은 툴링이나 데이터를 추가하는 등 에이전트에 대한 수동 업데이트 정보를 제공할 수 있습니다.

빌드 단계에서는 초기 프로토타입을 만들고, 최적화 단계에서는 도메인 전문가의 피드백을 엔진으로 사용하여 에이전트를 지속적으로 최적화함으로써 프로덕션으로의 전환을 가속화합니다.

아키텍처 개요

에이전트는 확률적 방식과 결정적 방식의 균형을 맞춥니다. 즉, LLM은 사용자 쿼리의 의미론적 의도를 해석하고 올바른 도구를 선택하는 반면, 결정론적 SQL 함수는 100% 정확도로 데이터를 가져옵니다. 예를 들어, 코치가 "상대팀이 블리츠를 어떻게 공략하나요?"라고 물으면 LLM은 이를 패스러시/커버리지 분석 요청으로 해석하고 success_by_pass_rush_and_coverage()를 선택합니다. SQL 함수는 기본 데이터에서 정확한 통계를 반환합니다. Unity Catalog 함수를 사용하여 통계의 100% 정확도를 보장하는 동시에 LLM이 대화 컨텍스트를 처리하도록 합니다.

DC 어시스턴트 구현의 코드 및 출력과 함께 각 단계를 살펴보겠습니다.

빌드

1. 데이터를 수집합니다.

설정 노트북(00_setup.ipynb) 워크플로 전체에서 사용되는 모든 전역 구성 변수(워크스페이스 카탈로그/스키마, MLflow Experiment, LLM Endpoint, 모델 이름, 평가 데이터세트, Unity Catalog 도구 이름, 인증 설정)를 정의합니다. 이 구성은 config/dc_assistant.json 에 유지되며 모든 다운스트림 노트북에서 로드되어 파이프라인 전반의 일관성을 보장합니다. 이 단계는 선택 사항이지만 전체적인 구성에 도움이 됩니다.

이 구성이 준비되면 nflreadpy 를 통해 축구 데이터를 로드하고 증분 처리를 적용하여 에이전트 사용을 위해 준비합니다. 즉, 사용하지 않는 열을 삭제하고 스키마를 표준화하며 정리된 Delta 테이블을 Unity Catalog에 유지합니다. 다음은 데이터 처리에 대해서는 많이 다루지 않고 데이터를 로드하는 간단한 예입니다.

이 프로세스의 출력은 도구 생성 및 에이전트 사용에 준비된 Unity Catalog의 관리형 Delta 테이블(플레이 바이 플레이, 참여, 로스터, 팀, 선수)입니다.

2. 도구를 만듭니다.

에이전트는 기본 데이터를 쿼리하기 위한 확정적 도구가 필요합니다. 다양한 상황별 차원에서 공격 성향을 계산하는 Unity Catalog SQL 함수로 이를 정의합니다. 각 함수는 team 및 season 과 같은 매개변수를 사용하여 코디네이터의 질문에 답하는 데 에이전트가 사용할 수 있는 집계된 통계를 반환합니다. 이 예시에서는 SQL 기반 함수만 사용하지만, 프로세스를 감독하는 LLM을 보완하기 위해 에이전트가 활용할 수 있는 추가 기능으로 Python 기반 UC 함수, 벡터 검색 인덱스, 모델 컨텍스트 프로토콜(MCP) 툴링 및 Genie spaces 를 구성할 수 있습니다.

다음 예시는 패스 러셔 수 및 수비 커버리지 유형별로 그룹화된 패스/런 분할, EPA(기대 득점 추가), 성공률, 획득 야드를 계산하는 success_by_pass_rush_and_coverage()를 보여줍니다. 이 함수에는 용도를 설명하는 COMMENT 가 포함되어 있으며, LLM은 이를 사용하여 언제 함수를 호출할지 결정합니다.

이러한 함수는 Unity Catalog에 있기 때문에 역할 기반 액세스 제어, 리니지 추적, 워크스페이스 전반의 검색 가능성과 같은 플랫폼의 거버넌스 모델을 상속합니다. 팀은 로직을 복제하지 않고 도구를 찾아 재사용할 수 있으며, 관리자는 에이전트가 어떤 데이터에 액세스할 수 있는지에 대한 가시성을 유지합니다.

3. 에이전트를 정의하고 배포합니다.

AI Playground를 사용하는 것만큼 간단하게 에이전트를 만들 수 있습니다. 사용하려는 LLM을 선택하고, Unity Catalog 도구를 추가하고, 시스템 프롬프트를 정의한 다음, '에이전트 노트북 만들기'를 클릭하여 ResponsesAgent 형식으로 에이전트를 생성하는 노트북을 내보냅니다. 다음 스크린샷은 이 워크플로가 실제로 작동하는 모습을 보여줍니다. 내보낸 노트북에는 에이전트 정의 구조가 포함되어 있으며, UCFunctionToolkit를 통해 UC 함수를 에이전트에 연결합니다.

자체 최적화 루프를 활성화하려면 시스템 프롬프트를 하드코딩하는 대신 Prompt Registry에 등록합니다. 이렇게 하면 최적화 단계에서 에이전트를 다시 배포하지 않고도 프롬프트를 업데이트할 수 있습니다.

에이전트 코드를 테스트하고 모델을 Unity Catalog에 등록하면 아래 코드처럼 간단하게 영구 endpoint에 배포할 수 있습니다. 이렇게 하면 MLflow Tracing이 활성화되고, 요청/응답 로깅을 위한 추론 테이블 및 자동 확장을 지원하는 Model Serving 엔드포인트가 생성됩니다.

최종 사용자 액세스를 위해 에이전트를 Databricks 앱으로 배포하여 코디네이터와 애널리스트가 노트북이나 API 액세스 없이 직접 사용할 수 있는 채팅 인터페이스를 제공할 수도 있습니다. 소개에 있는 스크린샷은 이 앱 기반 배포가 작동하는 모습을 보여줍니다.

4. 초기 평가.

에이전트가 배포되면 LLM 심사위원을 사용하여 자동 평가를 실행하고 기준 품질 측정을 설정합니다. MLflow는 여러 심사위원 유형을 지원하며, 저희는 세 가지를 조합하여 사용합니다.

기본 내장 심사위원 은 일반적인 평가 기준을 즉시 처리합니다. RelevanceToQuery() 는 응답이 사용자의 질문에 부합하는지 확인합니다. 가이드라인 기반 심사위원은 특정 텍스트 기반 규칙에 따라 통과/실패 방식으로 평가합니다. 응답이 적절한 전문 미식축구 용어를 사용하도록 보장하는 가이드라인을 다음과 같이 정의합니다.

사용자 지정 심사위원 은 채점 기준을 완전히 제어하여 도메인별 평가를 위해 make_judge() 를 사용합니다. 최적화 단계에서 SME 피드백에 맞춰 조정할 심사위원은 다음과 같습니다.

모든 심사위원이 정의되면 데이터 세트에 대한 평가를 실행할 수 있습니다.

사용자 지정 football_analysis_base 심사위원은 기준 점수를 제공하지만, 이는 진정한 도메인 전문 지식이라기보다는 LLM이 판단에 사용할 수 있는 루브릭을 처음부터 제공하려는 최선의 시도를 반영할 뿐입니다. MLflow Experiments UI는 이 베이스라인 심사자에 대한 에이전트의 성능과 각 예시의 점수에 대한 근거를 보여줍니다.

최적화 단계에서는 축구 분석 심사위원을 SME 선호도에 맞춰 조정하여 수비 코디네이터 분석에서 '좋다'는 것이 실제로 무엇을 의미하는지 학습시킵니다.

최적화

5. 전문가 피드백 수집.

에이전트 배포 및 베이스라인 평가가 완료되면 최적화 루프에 들어갑니다. 이 지점에서 도메인 전문 지식이 시스템에 인코딩됩니다. 처음에는 정렬된 LLM 심사위원을 통해, 그 다음에는 정렬된 심사위원이 안내하는 시스템 프롬프트 최적화를 통해 에이전트에 직접 인코딩됩니다.

make_judge()로 생성한 축구 분석 평가기와 동일한 지침 및 평가 기준을 사용하는 레이블 스키마를 생성하는 것으로 시작합니다. 그런 다음 도메인 전문가가 evaluate() 작업에 사용된 것과 동일한 추적에 대한 응답을 검토하고 검토 앱 (아래 그림)을 통해 점수와 피드백을 제공할 수 있도록 라벨링 세션을 생성합니다.

이 피드백은 심사자 조정을 위한 실측 자료가 됩니다. 기준 심사자와 SME 점수가 달라지는 지점을 살펴봄으로써 우리는 심사자가 이 특정 도메인에 대해 무엇을 잘못 판단하는지 알 수 있습니다.

6. 평가자 조정.

이제 도메인 전문가 피드백과 LLM 평가기 피드백이 모두 포함된 추적이 있으므로, MLflow align() 기능을 활용하여 LLM 평가기를 도메인 전문가 피드백에 맞게 조정할 수 있습니다. 조정된 심사위원은 도메인 전문가의 관점과 조직의 고유한 데이터를 반영합니다. 조정(Alignment)은 이전에는 불가능했던 방식으로 도메인 전문가를 개발 프로세스에 참여시킵니다. 즉, 도메인 피드백이 시스템의 품질 측정 방식을 직접적으로 형성하여 에이전트 성능 지표를 신뢰할 수 있고 확장 가능하게 만듭니다.

align() 을 사용하면 사용자 지정 옵티마이저 또는 기본 바이너리 SIMBA(Simplified Multi-Bootstrap Aggregation) 옵티마이저를 사용할 수 있습니다. 이 경우 리커트 척도 평가자를 보정하기 위해 사용자 지정 SIMBA 옵티마이저를 활용합니다.

다음으로, 프로세스 전반에 걸쳐 태그를 지정한 LLM 심사자 점수와 SME 피드백이 모두 포함된 추적 정보를 검색합니다. SIMBA는 이러한 쌍을 이룬 점수를 사용하여 일반적인 판단과 전문가의 판단 사이의 차이를 학습합니다.

다음 스크린샷은 진행 중인 조정 프로세스를 보여줍니다. 모델은 LLM 심사위원과 SME 피드백 간의 격차를 식별하고, 이러한 격차를 줄이기 위해 심사위원에 통합할 새로운 규칙과 세부 정보를 제안한 다음, 새로운 후보 심사위원이 기준 심사위원의 성능을 초과하는지 평가합니다.

이 프로세스의 최종 결과물은 자세한 지침과 함께 도메인 전문가의 피드백을 직접 반영하는 정렬된 judge입니다.

효과적인 조정을 위한 팁:

• 얼라인먼트의 목표는 개발 중에 도메인 전문가가 옆에 앉아 있는 것처럼 느끼게 해주는 것입니다. 이 과정으로 인해 기준 에이전트의 성능 점수가 낮아질 수 있으며, 이는 기준 평가자의 사양이 불충분했음을 의미합니다. 이제 SME와 동일한 방식으로 에이전트를 평가하는 평가자가 있으므로 수동 또는 자동 개선을 통해 성능을 향상시킬 수 있습니다.
• 정렬 프로세스의 품질은 제공된 피드백의 품질에 따라 결정됩니다. 양보다 질에 집중하세요. 많은 예시에 대해 일관성 없는 피드백을 주는 것보다 적은 수의 예시(최소 10개)에 대해 상세하고 일관된 피드백을 주는 것이 더 좋은 결과를 냅니다.

품질 정의는 종종 더 나은 에이전트 성능을 달성하는 데 가장 큰 장애물입니다. 최적화 기법과 관계없이 품질에 대한 명확한 정의가 없다면 에이전트 성능은 기대에 미치지 못할 것입니다. Databricks는 고객이 반복적이고 교차 기능적인 실습을 통해 품질을 정의하는 데 도움이 되는 워크숍을 제공합니다. 자세한 내용을 알아보려면 Databricks 계정 팀에 문의하거나 이 양식을 작성해 주세요.

7. 프롬프트 최적화.

SME 선호도를 반영하는 조정된 심사위원을 사용하면 이제 에이전트의 시스템 프롬프트를 자동으로 개선할 수 있습니다. MLflow의 optimize_prompts() 함수는 GEPA 를 사용하여 조정된 심사위원의 채점에 따라 프롬프트를 반복적으로 구체화합니다. Databricks CTO인 Matei Zaharia가 공동 제작한 GEPA(Genetic-Pareto)는 대규모 언어 모델을 활용하여 프롬프트에 대한 반성적 변이를 수행하는 유전적 진화 프롬프트 알고리즘으로, 이를 통해 지침을 반복적으로 구체화하고 모델 성능 최적화에서 기존 강화 학습 기술보다 뛰어난 성능을 발휘할 수 있습니다.

개발자가 시스템 프롬프트에 추가할 형용사를 추측하는 대신, GEPA 옵티마이저는 전문가가 정의한 특정 점수를 최대화하도록 프롬프트를 수학적으로 발전시킵니다. 최적화 프로세스는 옵티마이저를 바람직한 행동으로 유도하는 예상 응답이 포함된 데이터 세트를 필요로 합니다. 예를 들면 다음과 같습니다.

GEPA 옵티마이저는 현재 시스템 프롬프트를 가져와 조정된 평가자에 대해 각 후보를 평가하면서 반복적으로 개선 사항을 제안합니다. 여기서는 MLflow의 optimize_prompts()를 활용하기 위해 초기 프롬프트, 우리가 생성한 최적화 데이터세트, 그리고 조정된 평가자를 가져옵니다. 그런 다음 GEPA 옵티마이저를 사용하여 조정된 평가자의 안내에 따라 새로운 시스템 프롬프트를 만듭니다.

다음 스크린샷은 시스템 프롬프트의 변경 사항을 보여줍니다. 왼쪽이 기존 프롬프트이고 오른쪽이 새 프롬프트입니다. 최종적으로 선택된 프롬프트는 조정된 심사위원이 측정한 점수가 가장 높은 프롬프트입니다. 새 프롬프트는 공간상의 이유로 일부 생략되었지만, 이 예시를 통해 도메인 전문가의 응답을 통합하여 특정 요청 처리 방법에 대한 명시적인 지침과 함께 도메인별 언어에 기반한 프롬프트를 만들 수 있었음을 분명히 알 수 있습니다.

SME 피드백을 사용하여 이러한 유형의 지침을 자동으로 생성하는 기능을 통해 SME는 에이전트의 추적에 피드백을 제공하는 것만으로 에이전트에 간접적으로 지시를 내릴 수 있습니다.

이 경우, 얼라인된 심사위원에 따르면 새로운 프롬프트가 최적화 데이터 세트에서 더 나은 성능을 보였으므로, 새로 등록된 프롬프트에 프로덕션 별칭을 부여하여 개선된 프롬프트로 에이전트를 다시 배포할 수 있었습니다.

프롬프트 최적화를 위한 팁:

• 최적화 데이터세트는 에이전트가 처리할 다양한 쿼리를 포괄해야 합니다. 에지 케이스, 모호한 요청, 도구 선택이 중요한 시나리오를 포함하세요.
• 예상 응답은 정확한 출력 텍스트가 아니라 에이전트가 수행해야 할 작업(호출할 도구, 포함할 정보)을 설명해야 합니다.
• max_metric_calls 를 50 과 100 사이로 설정하여 시작하세요. 값이 높을수록 더 많은 후보를 탐색하지만 비용과 런타임이 증가합니다.
• GEPA 옵티마이저는 실패 모드에서 학습합니다. 조정된 심사위원이 누락된 벤치마크나 소규모 샘플 주의 사항에 페널티를 부과하면 GEPA는 이러한 요구 사항을 최적화된 프롬프트에 주입합니다.

8. 루프 마무리: 자동화 및 지속적인 개선.

지금까지 살펴본 개별 단계는 도메인 전문가의 레이블 지정이 최적화 루프의 trigger가 되는 연속 최적화 파이프라인으로 조정할 수 있으며, 모든 것은 자산 Bundles를 사용하는 Databricks 작업에 포함될 수 있습니다.

1. SME는 MLflow 레이블 지정 세션 UI를 통해 에이전트 출력에 레이블을 지정하고 실제 프로덕션 추적에 대한 점수와 의견을 제공합니다.
2. 파이프라인은 새로운 레이블을 감지하고 SME 피드백과 베이스라인 LLM 심사자 점수를 모두 포함한 추적 정보를 가져옵니다.
3. 심사자 정렬이 실행되어 최신 SME 선호도에 맞춰 보정된 새로운 심사자 버전이 생성됩니다.
4. 프롬프트 최적화가 실행되며, 조정된 평가자를 사용하여 시스템 프롬프트를 반복적으로 개선합니다.
5. 조건부 프로모션은 성능 임계값을 초과하는 경우 새 프롬프트를 프로덕션으로 푸시합니다. 여기에는 새 프롬프트가 다른 예시에도 일반화되는지 확인하기 위해 또 다른 평가 작업을 트리거하는 과정이 포함될 수 있습니다.
6. 프롬프트 레지스트리가 최적화된 버전을 제공하므로 에이전트는 자동으로 개선됩니다.

도메인 전문가가 라벨링 세션을 완료하면 evaluate() 작업이 Trigger되어 동일한 추적에 대한 LLM 심사위원 점수를 생성합니다. evaluate() 작업이 완료되면 도메인 전문가 피드백에 LLM 심사자를 맞추기 위해 align() 작업이 실행됩니다. 해당 작업이 완료되면 optimize_prompts() 작업이 실행되어 새롭고 개선된 시스템 프롬프트를 생성합니다. 이 프롬프트는 새 데이터 세트에 대해 즉시 테스트할 수 있으며, 적절한 경우 프로덕션으로 승격될 수 있습니다.

이 전체 프로세스는 완전히 자동화될 수 있지만, 어떤 단계에서든 수동 검토를 추가하여 개발자가 관련 자동화 수준을 완벽하게 제어할 수 있도록 할 수 있습니다. SME(주제 전문가)가 계속 레이블을 지정함에 따라 프로세스가 반복되어 에이전트의 새 버전에 대한 빠른 성능 테스트로 이어지며, 개발자가 실제로 신뢰할 수 있는 누적 성능 향상을 가져옵니다.

결론

이 아키텍처는 Databricks Agent Framework와 MLflow를 사용하여 시간이 지남에 따라 에이전트가 개선되는 방식을 혁신합니다. 개발자가 좋은 응답이 무엇인지 추측하는 대신, 도메인 전문가가 전문가 피드백을 통해 에이전트의 동작을 직접 형성합니다. 평가자 정렬 및 최적화 프로세스는 도메인 전문 지식을 구체적인 시스템 변경으로 변환하는 동시에, 개발자는 어떤 부분을 자동화하고 어디에서 수동 개입을 허용할지를 포함하여 전체 시스템에 대한 제어권을 유지합니다.

이 게시물에서는 프로 미식축구 도메인 전문가에게 중요한 특정 언어와 세부 정보를 반영하도록 에이전트를 맞춤화하는 방법을 설명했습니다. DC 어시스턴트는 이 패턴을 보여주지만, 이 접근 방식은 법률 문서 검토, 프로 야구 타석 준비, 의료 분류, 골프 샷 분석, 고객 지원 에스컬레이션 또는 도메인 전문가의 지원 없이는 개발자가 '좋음'을 지정하기 어려운 기타 모든 애플리케이션과 같이 전문가의 판단이 중요한 모든 도메인에서 효과적입니다.

자신만의 도메인별 문제에 적용해 보고 SME 피드백을 기반으로 자동화되고 지속적인 개선을 어떻게 이끌어낼 수 있는지 확인해 보세요!

Databricks Sports 및 Agent Bricks에 대해 자세히 알아보거나 데모를 요청하여 조직이 경쟁 우위의 인사이트를 확보하는 방법을 확인하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)