- 데이터 에이전트의 실력을 판단하려면
SQL 생성을 넘어 여러 데이터베이스 결합, 도메인 지식 활용, 비정형 데이터 처리까지 평가해야 함
- 실제 분석 환경을 반영한 벤치마크에서 최고 에이전트의
단일 시도 통과율은 약 61% 였으며, 질의별 프롬프트 최적화로 얻은 더 높은 점수를 현실적인 성능과 구분해야 함
시맨틱 레이어를 제공하면 정확도가 크게 올라가며, 원시 데이터에 바로 연결하는 환경과 정제된 골드 테이블 및 시맨틱 레이어를 제공하는 환경은 구분해야 함
- LLM 평가에서도 사람이
충분한 출력을 직접 확인해야 하며, 결과를 보면서 원하는 기준 자체가 바뀌는 평가 기준 변화(criteria drift) 때문에 처음 만든 평가표를 그대로 신뢰하기 어려움
AI SQL은 비정형 데이터 분석을 SQL 안으로 가져오지만 행마다 LLM을 호출하는 비용이 크며, 호출 수 절감을 넘어 전용 추론 엔진과 질의 계획 최적화가 연구 과제임
AI가 작성하는 연락 이메일과 프롬프트 인젝션
-
Shreya는 연구 참여를 요청하면서 논문별로 긴 감상을 나열하는
AI 생성 이메일에 대응해, 웹사이트에 에이전트 대상 지시문을 넣음
-
사용자의 연락 목적을 원문 그대로 밝히고, 사용한 도구와 검색 및 웹페이지, 함께 연락하는 다른 사람을 이메일에 포함하도록 요구함
-
지시를 따랐다는 표시로 이메일을 “The latent space brought me here”로 시작하도록 함
-
설치 후 첫 주 안에 이메일이 하루 약 5통에서 주당 약 3통으로 줄었지만,
통계적 분석은 하지 않았음
-
지정 문구가 들어간 이메일은 단 한 통이었음
-
대량으로 교수를 찾는 에이전트가 해당 지시문 때문에 이메일 작성을 건너뛰었을 가능성이 있지만, 실제 원인은 확인하지 못함
-
개인별 맥락을 조사해 작성하는 이메일은 사람이 보낸 연락과 구분하기 어려워
기존 스팸 대응에 새로운 문제를 만듦
-
Shreya는 오히려 AI 없이 직접 쓴 이메일이 눈에 띌 수 있다며 직접 작성을 권함
AI와 데이터베이스 사이의 연구 문제
- 스타트업에서 머신러닝을 적용할 때 부딪힌 문제는 모델보다
데이터 준비와 데이터 엔지니어링에 가까웠음
- 사람이 모든 질의를 손으로 조정하기보다, 원하는 작업을 선언하면 시스템이 최적화하는 방식에 관심을 갖게 됨
학문 분야의 문화와 전통은 어떤 문제를 연구하고 어떻게 평가하는지에 영향을 줌
-
AI와 데이터베이스 전문성이 분리돼 있으면 두 영역에 걸친 문제를 풀기 어려움
-
데이터베이스 분야는 관계형 시스템의 철학을 머신러닝 기반 질의 처리, ETL 등 새로운 응용으로 확장해 왔음
-
LLM을 활용한 비정형 데이터 처리는 기존
크라우드소싱 기반 데이터 관리와 연결됨
-
사람이 이미지를 분류하거나 정렬하는 작업도 질의 처리 문제로 볼 수 있으며, LLM으로 유사한 작업을 수행하는 시스템을 만들 수 있음
-
연구 범위는 LLM으로 데이터 처리를 수행하는 것에서,
에이전트를 데이터 시스템의 주요 사용자로 취급하는 것으로 넓어짐
-
에이전트가 데이터를 이해하도록 어떤 도구와 스킬을 설계할지가 중요해짐
질문에 답하는 내부 루프와 질문을 찾는 외부 루프
-
데이터 도구에는 주어진 질문을 빠르고 정확하게 실행하는
내부 루프와, 무엇을 물어야 할지 찾도록 돕는 외부 루프가 있음
-
데이터베이스는 전자에, BI 도구는 후자에 가까움
-
분석가도 요청에 답하는 역할에서 더 나아가, 스스로 흥미로운 질문을 찾아내는 역할을 수행함
-
BI의 중요한 혁신은
시각화를 통해 사람의 전주의적 처리 능력을 활용한 것임
-
사람은 그래프를 보며 복잡한 추론에 앞서 패턴이나 질문거리를 알아챌 수 있음
-
데이터 에이전트에는 이에 대응하는 처리 경로가 아직 뚜렷하지 않음
-
에이전트용 도구는 사람용 인터페이스와 달라야 하며,
Datadog의 MCP가 그 사례임
-
단순히 인터페이스를 제공하는 것을 넘어, 읽어야 할 토큰 수와 도구 호출 수를 줄여야 함
-
높은 수준의 질문에 답하기 위해 디렉터리 탐색이나 여러 차례의 셸 호출을 반복하지 않도록 해야 함
-
연구 질문은 “어떤 정보를 프롬프트에 제공해야
추론 토큰을 덜 쓰고 정답에 도달하는가”로 구체화할 수 있음
-
반복적으로 쓰는 분석 패턴과 추론 논리를 프롬프트나 모델에 반영할 수 있다는 가설이 있지만, 답은 아직 명확하지 않음
SQL과 관계대수의 가치는 사람이 SQL을 잘 쓴다는 데 있지 않고, 비즈니스 데이터를 잘 모델링한다는 데 있음
- 에이전트가 질의를 작성하더라도 이 언어적 기반은 계속 유효할 가능성이 있음
SQL 생성만으로는 분석 능력을 측정할 수 없음
-
평가 대상인
데이터 에이전트는 여러 데이터베이스와 기존 분석 도구를 사용해, 사람이 맡을 법한 비즈니스 질문에 답하는 주니어 분석가에 가까움
-
흥미로운 질문을 스스로 찾는 능력은 범위에서 제외함
-
매출 계산이나 반복 구매하지 않는 고객의 우선순위 결정처럼, 검증 가능한 답이 있는 질문에 집중함
-
기존
텍스트-SQL 변환 벤치마크는 실제 분석 업무보다 범위가 좁음
-
분석가는 SQL만 작성하지 않고, 여러 데이터 도구를 연결하고 서로 다른 데이터베이스의 데이터를 가공함
-
깨끗하고 정형화된 평가 환경만으로는 이런 작업을 얼마나 잘하는지 알기 어려움
테이블 질의응답 방식은 CSV나 테이블 전체를 모델 문맥에 넣지만, 실제 데이터는 문맥 창보다 크며 비용도 발생함
-
관계대수로 처리할 수 있는 질의라면 데이터베이스를 사용하는 편이 적절함
-
데이터 웨어하우스 전체를 모델 문맥에 넣는 방식은 최종 사용자의 데이터 처리 방식으로 적합하지 않음
-
다만 LLM이 문맥 안에서
열 선택, 필터링, 조인을 수행할 수 있는지는 별개의 흥미로운 연구 문제임
-
긴 문맥에서 특정 정보를 찾는 평가보다 관계 연산 능력을 묻는 평가가 더 흥미로울 수 있음
-
모든 토큰 쌍을 다루는 모델의 계산 방식은 일반 프로그램의 관계 연산과 다르며, 그 이론적 특성을 충분히 이해하지 못하고 있음
현실적인 분석 환경을 만드는 벤치마크
- 벤치마크는 실무자와의 대화를 바탕으로
여러 데이터베이스가 공존하는 환경을 반영함
- 서로 다른 저장소에서 데이터를 가져와 계산하거나 조인해야 함
- 핵심은 가능한 계산을 원본 데이터베이스로 밀어 넣는
연산 푸시다운임
- 에이전트는 종종
SELECT *
로 데이터를 전부 가져와 Pandas에서 조인하려 하지만, 큰 데이터 웨어하우스에는 부적절한 방식임
도메인 지식과 조직 내부 지식도 필요함
-
주식 종목 기호나 이동평균의 의미처럼 데이터 해석에 필요한 지식을 활용해야 함
-
벤치마크는 일부 지식을 메모리 파일로 제공하며, 실제 기업에서는 지식 그래프나 내부에 축적된 지식이 이 역할을 할 수 있음
-
일부 질의는
비정형 데이터 변환을 요구함
-
자유 텍스트 열을 해석해 우선순위가 높은 고객 지원 티켓 등을 결정해야 함
-
기존 분석가는 데이터를 변환하고 분류 모델을 실행하는 식으로 처리하며, 에이전트도 이런 과정을 수행할 수 있어야 함
-
이 과정에서도 전체 질의 계획을 고려해 불필요한 데이터 이동과 계산을 줄여야 함
-
공개 데이터를 바탕으로 필요한 조건이 드러나도록 데이터를 의도적으로 훼손하며 평가 환경을 구축했고,
약 8개월이 걸림
성능 개선과 리더보드 과적합
-
대화 시점의 미공개 개정판에서는 질의 집합을 확대했고, 성능이 이전보다
약 20%포인트 상승함
-
모델의 코드 작성 능력이 개선됐으며, 자체 하네스를 만들기보다 모델 제공 측의 기본 하네스를 사용함
-
가장 좋은 에이전트의
pass@1은 약 61% 로, 질의당 한 번의 시도에서 통과한 비율임
-
리더보드의
80%대 점수는 동일하게 해석하기 어려움
-
일부 참가자는 특정 질문의 해결 절차를 프롬프트에 직접 넣거나, 질의마다 별도 프롬프트를 작성함
-
이런 방식은 실제 사용 환경에서 실행하기 어렵고, 벤치마크 운영자도 정당한 개선과 과적합을 구분하기 어려움
-
강하게 프롬프트를 최적화한 경우 약
85% 에 도달하지만, 여전히 해결하지 못하는 질의가 남음
-
이런 실행에는 큰 비용이 들 수 있으며, 벤치마크 한 번에 약 1만 달러가 들 수 있다는 추정도 있음
시맨틱 레이어가 바꾸는 평가 조건
시맨틱 레이어를 제공하는 변형에서는 정확도가 크게 상승함
-
데이터 엔지니어와 분석 엔지니어가 데이터를 같은 관계형 저장소에 정리하고, 키를 맞추고, 맥락과 시맨틱 레이어를 준비한 뒤 에이전트에 넘기는 환경은 원시 데이터 환경과 다름
-
시맨틱 레이어는 여전히
사람이 내용을 이해하고 관리해야 하는 어려운 작업임
-
에이전트가 생성했다고 해서 품질 기준이 낮아지는 것은 아님
-
에이전트를 잘 활용하면 구축이 조금 쉬워질 수 있지만, 부정확한 레이어는 후속 분석에도 영향을 줌
원시 데이터에 바로 연결하면 시행착오가 많을 가능성이 높고, 정제된 골드 테이블과 시맨틱 레이어를 제공하면 더 나은 결과를 기대할 수 있음
- 다만 잘 정리된 골드 테이블을 갖춘 곳은 많지 않음
- 같은 조직 안에서도 깨끗하게 정리된 일부 데이터와 방대한 원시 데이터가 공존하므로, 적용 범위를 구분해야 함
LLM 심판과 평가 기준 변화
「Who Validates the Validators」 는 LLM 심판을 없애자는 연구가 아니라, 개발자가 평가 결과를 신뢰하도록 만드는 과정을 탐구함
- 주관적이고 평가하기 어려운 기준을 대규모로 적용하려면 LLM 심판이 필요함
- GPT-4 출시 직후 사용자 연구를 수행했으며, 이후 LLM 심판은 학습과 강화학습 등에도 널리 쓰이게 됨
능동 학습과 대화형 머신러닝을 활용해, 개발자의 실시간 라벨로 평가 프롬프트를 합성하는 방식을 실험함
-
처음부터 대량의 정답 라벨을 준비하기는 어렵지만, 인터페이스에서 결과를 보며 라벨을 붙일 수는 있음
-
LLM 파이프라인 구축 도구인
ChainForge 위에 프로토타입을 만듦
-
예상 밖의 장애물은
평가 기준 변화였음
-
사람은 결과를 충분히 보기 전까지 무엇을 원하는지 명확히 알지 못함
-
출력을 보며 문제 영역을 새로 이해하거나, 모델이 잘하는 작업을 발견하면서 기준을 바꿈
-
상품 리뷰 요약에서 모델이 특정 측면을 예상보다 잘 요약한다면, 그 장점을 활용하도록 평가표를 바꿀 수도 있음
-
LLM 심판을 신뢰하려면 먼저 사람이
충분한 표본을 직접 확인하고 평가표에 확신을 가져야 함
-
데이터와 AI뿐 아니라, 사람이 결과를 해석하고 의사결정하는 HCI 문제까지 연결됨
사람의 반응을 얻는 폐쇄형 평가 루프
Meta의 광고망은 AI 생성 결과에 대한 사람의 반응을 다시 측정할 수 있는 평가 구조의 사례임
-
콘텐츠를 생성하고 배포한 뒤 어떤 결과가 사람의 상호작용을 유발하는지 확인할 수 있음
-
이런 구조에는
배포 수단과 피드백 확보 능력이 함께 필요함
-
모든 광고 사업자가 같은 조건을 갖추는 것은 아님
-
AI 출력에 대한 사람의 피드백을 어떻게 얻을 것인지가 사업 모델 차원의 질문이 될 수 있음
새 모델이 나오면 평가가 필요 없어질까?
「Defense of AI Evals」 는 새 모델이 충분히 좋아졌으니 평가를 하지 않아도 된다는 온라인 논쟁에서 출발함
-
평가와 프롬프트 개선에 공들인 것보다 다음 모델을 기다리는 편이 성능 향상에 더 도움이 됐다는 실망이 논쟁의 한 원인으로 보임
-
Shreya의 경험에서는
새 모델이 품질과 비용의 파레토 경계를 가장 크게 이동시킴
-
최종 사용자가 할 수 있는 프롬프트 조정과 하네스 개선도 유용하지만, 개선 폭에는 한계가 있음
-
최근 성능 향상 중
모델과 하네스의 기여도를 명확히 나누기는 어려움
-
서로 다른 모델의 차이는 여전히 크며, 충분히 사용해야 드러나는 경우도 있음
-
모델별 강점은 과제에 따라 들쭉날쭉하고, 반복적인 작업에는 더 작은 모델로 충분할 수 있음
-
사용자는 전체 과제 공간의 일부만 경험하므로 자신의 경험만으로 일반화하기 어려움
실무 평가의 출발점은 출력 직접 보기
-
데이터 분석에서 익숙한 “
데이터를 직접 보라”는 원칙은 에이전트 평가에도 그대로 적용됨
-
출력을 보지 않고서는 에이전트가 무엇을 하는지 제대로 판단하기 어려움
-
구조화된 데이터의
탐색적 데이터 분석(EDA) 은 비정형 에이전트 출력에 그대로 옮겨지지 않음
-
데이터프레임 요약이나 이상치 탐지처럼 널리 쓰이는 기능에 대응하는 도구가 부족함
-
현재는 스프레드시트에서 LLM 출력을 행별로 읽고 평가표를 만든 뒤, 다른 LLM 심판의 결과를 다시 읽는 식으로 작업하는 경우가 많음
-
당장은
행별 검토를 생략하지 않고 체계적으로 수행하는 것이 좋음
-
기존 EDA 기법을 응용해 출력을 임베딩하고 군집화해 볼 수 있음
-
다만 임베딩이 출력의 중요한 특성을 잘 표현한다는 보장이 없고, 해석도 어려워 구조화된 데이터 군집화만큼 명확하지 않음
-
필요한 처리 코드를 직접 작성해야 하는 등 도구의 미성숙함이 남아 있음
AI SQL의 비용과 전용 추론 엔진
Snowflake, Google BigQuery, Databricks는 SQL 안에서 AI 연산자를 사용하는 기능을 제공함
-
특정 방식으로 제품에 불만을 표현한 고객 리뷰를 필터링하는 등, 비정형 데이터 해석을 질의 안에 넣을 수 있음
-
유용하지만 질의 비용이 수십만 달러로 커지는 사례도 있어 최적화가 중요함
-
현재 구현의 주요 문제는
행별 LLM 호출임
-
각 행의 프롬프트를 별도 HTTP 요청으로 외부 모델에 보내는 방식은 비용이 큼
-
집계 시 표본 추출을 하거나 작은 모델을 쓰면 호출 비용을 줄일 수 있지만, 여전히 행 단위 호출 구조에 머무름
-
진행 중인 연구는
AI SQL 전용 추론 엔진을 만드는 것임
-
공개 모델의 성능 향상을 활용하고, 질의 계획과 논리적 재작성을 추론 실행에 연결하려 함
-
AI 연산을 가능한 한
프리필(prefill) 중심으로 만들고 디코딩을 없애는 방향을 탐구함
-
대규모 실행과 필요한 모델 지원도 과제임
-
인프라 측면의 장애물은
데이터베이스와 GPU가 보통 함께 배치되지 않는다는 점임
-
AI 활용이 데이터베이스 가까이에 GPU를 두는 계기가 되기를 기대하지만, 아직 확정된 변화는 아님
-
데이터 분야의 AI 수요를 단순한 모델 호출로만 구현하는 데서 벗어나,
데이터베이스 내부 구조와 질의 최적화 전문성을 결합해야 함
댓글과 토론