AI 에이전트 평가: Elastic이 에이전트 프레임워크를 테스트하는 방법

Agent Builder는 현재 기술 미리보기 버전으로 제공됩니다. Elastic Cloud 체험판으로 시작한 뒤, Agent Builder 문서를 여기에서 확인하세요.

소개

Elastic Stack에는 곧 출시될 에이전트 빌더의 Elastic AI 에이전트(현재 기술 프리뷰 중)와 공격 탐색 (8.18 및 9.0+의GA) 과 같은 많은 LLM 기반 에이전트 애플리케이션이 있으며, 더 많은 애플리케이션이 개발 중입니다. 개발 중은 물론 배포 후에도 이러한 질문에 답하는 것이 중요합니다:

• 이러한 AI 애플리케이션의 응답 품질을 어떻게 평가할 수 있을까요?
• 변경을 하는 경우, 변경이 진정으로 개선된 것이며 사용자 경험의 저하를 초래하지 않는다고 어떻게 보장할 수 있을까요?
• 이러한 결과를 반복 가능한 방식으로 쉽게 테스트하려면 어떻게 해야 할까요?

기존의 소프트웨어 테스트와 달리, 생성 AI 애플리케이션을 평가하려면 통계적 방법, 미묘한 정성적 검토, 사용자 목표에 대한 깊은 이해가 필요합니다.

이 문서에서는 Elastic 개발자 팀이 평가를 수행하고, 배포 전에 변경 사항의 품질을 보장하고, 시스템 성능을 모니터링하기 위해 사용하는 프로세스에 대해 자세히 설명합니다. 모든 변화가 증거에 의해 뒷받침되어 신뢰할 수 있고 검증 가능한 결과로 이어질 수 있도록 노력합니다. 이 프로세스의 일부는 오픈 소스 정신의 일부로서 투명성에 대한 우리의 약속을 반영하여 Kibana에 직접 통합되어 있습니다. 평가 데이터와 메트릭의 일부를 공개적으로 공유함으로써 커뮤니티의 신뢰를 증진하고 AI 에이전트를 개발하거나 제품을 활용하는 모든 사람에게 명확한 프레임워크를 제공하고자 합니다.

제품 예시

이 문서에서 사용된 방법은 공격 탐색 및 Elastic AI 에이전트와 같은 솔루션을 반복하고 개선하는 방법의 기초가 되었습니다. 두 가지에 대해 각각 간략하게 소개합니다:

Elastic Security의 공격 탐색

공격 탐색은 LLM을 사용해 Elastic에서 공격 시퀀스를 식별하고 요약합니다. 지정된 기간(기본 24시간)에 Elastic Security 경보가 주어지면, 공격 탐색의 에이전트 워크플로우가 자동으로 공격이 발생했는지 여부와 침해된 호스트 또는 사용자, 결론에 기여한 경보와 같은 중요한 정보를 찾아냅니다.

목표는 LLM 기반 솔루션이 최소한 사람만큼 좋은 결과물을 만들어내는 것입니다.

Elastic AI 에이전트

Elastic 에이전트 빌더는 모든 검색 기능을 활용하는 상황 인식 AI 에이전트를 구축하기 위한 새로운 플랫폼입니다. 사용자가 대화형 상호 작용을 통해 데이터를 이해하고 데이터로부터 답을 얻을 수 있도록 설계된 사전 구축된 범용 에이전트인 Elastic AI 에이전트가 함께 제공됩니다.

에이전트는 Elasticsearch 또는 연결된 지식 기반 내에서 관련 정보를 자동으로 식별하고 사전 구축된 도구 모음을 활용하여 이들과 상호 작용함으로써 이를 달성합니다. 이를 통해 Elastic AI 에이전트는 단일 문서에 대한 간단한 질문(&A)부터 여러 인덱스에 걸친 집계와 단일 또는 다단계 검색이 필요한 복잡한 요청까지 다양한 범위의 사용자 쿼리에 응답할 수 있습니다.

실험을 통한 개선 사항 측정

AI 에이전트의 맥락에서 실험이란 잘 정의된 차원(예: 유용성, 정확성, 지연 시간)에서 성능을 개선하기 위해 설계된 시스템에 대한 구조적이고 테스트 가능한 변경을 의미합니다. 목표는 확실한 답을 찾는 것입니다: "이 변경 사항을 병합하면 진정한 개선이 이루어지고 사용자 경험이 저하되지 않는다고 보장할 수 있는가?"라는 질문에 확실히 답하는 것입니다.

저희가 수행하는 대부분의 실험에는 일반적으로 다음이 포함됩니다:

• 가설: 구체적이고 검증 가능한 주장. 예시: "공격 검색 도구에 대한 액세스 권한을 추가하면 보안 관련 쿼리의 정확도가 향상됩니다."
• 성공 기준: '성공'의 의미를 정의하는 명확한 임계값을 설정하세요. 예시: "보안 데이터 집합의 정확도 점수 +5% 개선, 다른 곳에서는 성능 저하 없음."
• 평가 계획: 성공 측정 방법(지표, 데이터 세트, 비교 방법)

성공적인 실험은 체계적인 탐구 과정입니다. 사소한 프롬프트 조정부터 대대적인 아키텍처 변경에 이르기까지 모든 변경은 이 7단계에 따라 의미 있고 실행 가능한 결과를 보장합니다:

• 1단계: 문제 식별
• 2단계: 지표 정의
• 3단계: 명확한 가설 수립하기
• 4단계: 평가 데이터 세트 준비
• 5단계: 실험 실행
• 6단계: 결과 분석 + 반복하기
• 7단계: 의사 결정 및 문서화

이러한 단계의 예는 그림 1에 나와 있습니다. 다음 하위 섹션에서는 각 단계에 대해 설명하며, 다음 문서에서 각 단계의 기술적 세부 사항에 대해 자세히 설명할 예정입니다.

실제 Elastic 예제를 통한 단계별 안내

1단계: 문제 식별

이 변경으로 해결하고자 하는 문제는 정확히 무엇인가요?

공격 탐지 예시: 요약이 불완전하거나 양성 활동이 공격으로 잘못 플래그가 지정되는 경우(오탐): 간혹 요약이 불완전합니다.

Elastic AI 에이전트 예시: 특히 분석 쿼리에 대한 에이전트의 도구 선택이 최적이 아니며 일관성이 없어 종종 잘못된 도구가 선택되는 경우가 있습니다. 이는 결과적으로 토큰 비용과 지연 시간을 증가시킵니다.

2단계: 지표 정의

문제를 측정 가능하게 만들어 현재 상태와 변경 사항을 비교할 수 있도록 합니다.

일반적인 측정지표에는 정확도 및 회수율, 의미적 유사성, 사실성 등이 포함됩니다. 사용 사례에 따라 코드 검사를 사용하여 경고 ID 일치 또는 올바르게 검색된 URL과 같은 메트릭을 계산하거나 보다 자유로운 형식의 답변을 위해 LLM-as-judge와 같은 기법을 사용하여 메트릭을 계산합니다.

다음은 실험에 사용된 몇 가지 지표의 예시(전부는 아님)입니다:

공격 탐지

Elastic AI 에이전트

3단계: 명확한 가설 수립하기

위에서 정의한 문제와 지표를 사용하여 명확한 성공 기준을 설정하세요.

Elastic AI 에이전트 예시:

1. 특정 기능과 사용 사례를 명확하게 정의하기 위해 relevance_search 및 nl_search 도구의 설명을 변경하여 구현합니다.
2. 도구 호출 정확도가 25 % 향상될 것으로 예상됩니다 %.
3. 다른 지표에 부정적인 영향을 미치지 않는지 확인하여 이것이 순 긍정적인지 확인할 것입니다. 사실성과 완전성.
4. 정확한 도구 설명은 상담원이 다양한 쿼리 유형에 가장 적합한 검색 도구를 보다 정확하게 선택하고 적용하는 데 도움이 되어 잘못된 적용을 줄이고 전반적인 검색 효율성을 개선할 수 있기 때문입니다.

4단계: 평가 데이터 세트 준비

시스템의 성능을 측정하기 위해 실제 시나리오를 캡처한 데이터 세트를 사용합니다.

수행하는 평가 유형에 따라 LLM에 공급되는 원시 데이터 등 다양한 유형의 데이터 형식이 필요할 수 있습니다(예 공격 발견을 위한 공격 시나리오) 및 예상 결과물입니다. 애플리케이션이 챗봇인 경우 입력은 사용자 쿼리일 수 있고 출력은 올바른 챗봇 응답, 검색했어야 하는 올바른 링크 등이 될 수 있습니다.

공격 발견 예시:

Elastic AI 에이전트 평가 데이터 세트 예제(Kibana 데이터 세트 링크):

5단계: 실험 실행

평가 데이터 세트에 대해 기존 에이전트와 수정된 버전 모두에서 응답을 생성하여 실험을 실행합니다. 사실 여부와 같은 지표를 계산합니다(2단계 참조).

2단계에서 요구되는 메트릭을 기반으로 다양한 평가를 혼합합니다:

• 규칙 기반 평가(예 파이썬/타입스크립트를 사용하여 .json이 유효한지 확인)
• LLM-as-judge(응답이 원본 문서와 사실적으로 일치하는지 별도의 LLM에게 문의)
• 뉘앙스 품질 검사를 위한 휴먼 인 더 루프 검토

6단계: 결과 분석 + 반복하기

이제 메트릭을 확보했으니 결과를 분석합니다. 결과가 3단계에서 정의한 성공 기준을 충족하더라도 변경 사항을 프로덕션에 병합하기 전에 인적 검토를 거치고, 기준에 부합하지 않으면 문제를 반복하여 수정한 다음 새 변경 사항에 대한 평가를 실행합니다.

병합하기 전에 최적의 변경 사항을 찾으려면 몇 번의 반복이 필요할 것으로 예상됩니다. 커밋을 푸시하기 전에 로컬 소프트웨어 테스트를 실행하는 것과 마찬가지로, 오프라인 평가도 로컬 변경 사항 또는 여러 제안된 변경 사항으로 실행할 수 있습니다. 실험 결과, 종합 점수 및 시각화 저장을 자동화하여 분석을 간소화하는 데 유용합니다.

7단계: 의사 결정 및 문서화

의사 결정 프레임워크와 승인 기준에 따라 변경 사항 병합을 결정하고 실험을 문서화합니다. 의사 결정은 다면적이며 다른 데이터 세트에 대한 회귀 시나리오를 확인하거나 제안된 변경의 비용 편익을 평가하는 등 평가 데이터 세트 이외의 요소를 고려할 수 있습니다.

예시: 몇 번의 반복을 테스트하고 비교한 후 가장 높은 점수를 받은 변경 사항을 선택하여 제품 관리자 및 기타 관련 이해 관계자에게 보내 승인을 받습니다. 이전 단계의 결과를 첨부하여 결정을 내리는 데 도움이 되도록 합니다. 공격 탐색 측면에 대한 더 많은 예는 Elastic Security의 생성형 AI 기능의 비하인드 스토리를 참조하세요.

결론

이 블로그에서는 실험 워크플로우의 엔드투엔드 프로세스를 살펴보면서 Elastic 사용자에게 변경 사항을 릴리즈하기 전에 에이전트 시스템의 변경 사항을 평가하고 테스트하는 방법을 설명합니다. 또한 Elastic에서 에이전트 기반 워크플로우를 개선하는 몇 가지 예도 제공했습니다. 다음 블로그 게시물에서는 좋은 데이터 집합을 만드는 방법, 신뢰할 수 있는 메트릭을 설계하는 방법, 여러 메트릭이 관련된 경우 의사 결정을 내리는 방법 등 다양한 단계의 세부 사항에 대해 자세히 설명합니다.