AI 에이전트는 모델을 호출해야 합니다

MLAT 논문은 에이전트가 XGBoost 가격 책정 모델을 도구로 호출하는 프로덕션 파일럿을 소개합니다. 이 시스템은 검증용 보류 데이터에서 R^2 = 0.807을 달성했고, 평균 절대 오차 3688 USD를 보고했으며, 제안서 생성 시간을 몇 시간에서 10분 미만으로 줄였습니다.¹

핵심은 특정 가격 책정 모델 자체가 아닙니다. 핵심은 경계입니다. 어떤 작업에 점수, 예측, 가격, 위험 추정, 순위, 분류기, 감지기가 필요하다면 에이전트는 그 일을 위해 학습된 모델을 호출해야 합니다. 유창한 문장으로 통계적 답을 즉석에서 만들어내면 안 됩니다.

학습된 모델은 에이전트 도구 등록부에 들어가야 합니다. LLM은 언제 호출할지 판단하고, 결과를 설명하고, 빠진 입력을 요청하고, 예외를 라우팅할 수 있습니다. 적합된 모델은 수치 추정값, 신뢰 신호, 버전이 붙은 출력, 증거 추적 기록을 생성해야 합니다.

요약

LLM 에이전트는 조율에 강합니다. 통계 모델과 머신러닝 모델은 범위가 정해진 예측에서 더 나은 경우가 많습니다. Machine Learning as a Tool 패턴은 적합된 ML 모델을 에이전트 작업 흐름 안에서 호출 가능한 도구로 다룹니다. 검색, 데이터베이스, API, 기타 도구와 나란히 배치하는 방식입니다.¹

이 패턴은 팀에 명확한 운영 원칙을 줍니다. 에이전트가 작업을 조율하게 하되, 전문화된 추론은 전문 모델이 맡게 하세요. 결과에는 모델 버전, 입력 스키마, 출력 스키마, 보정 메모, 추적 가능한 호출 기록이 포함되어야 합니다. 이 경계가 없으면 LLM은 확신에 찬 말투를 내면서 실제로는 모델을 추측으로 조용히 대체할 수 있습니다.

핵심 요점

• 에이전트 빌더에게: 학습된 모델을 스키마, 버전, 실패 모드를 갖춘 타입 지정 도구로 노출하세요.
• ML 팀에게: 에이전트를 호출자로 다루세요. 모델 평가, 영속화, 등록부 규율을 대체하는 존재로 보지 마세요.
• 제품 팀에게: 어떤 숫자가 모델 호출, 규칙, 데이터베이스, LLM 설명 중 어디에서 왔는지 보여주세요.
• 보안 팀에게: 에이전트 키에는 위험 예산이 필요합니다에서 다룬 범위 제한 권한 논리를 모델 도구에도 적용하세요.
• 검토자에게: 답을 신뢰하기 전에 모델 호출, 모델 버전, 입력, 출력, 신뢰 한계를 요구하세요.

왜 에이전트는 모델을 흉내 내지 말고 호출해야 할까요?

LLM은 가격을 논할 수 있습니다. 가격 책정 모델은 학습한 특징을 바탕으로 가격을 추정할 수 있습니다. LLM은 위험을 요약할 수 있습니다. 위험 모델은 검증된 특징 집합으로 위험을 점수화할 수 있습니다. LLM은 이탈을 설명할 수 있습니다. 이탈 모델은 학습 과정과 연결된 확률을 반환할 수 있습니다.

이것들은 서로 다른 일입니다.

에이전트 도구는 이미 이런 분리를 가능하게 합니다. OpenAI의 Agents SDK 문서는 JSON Schema 매개변수, 도구 호출 처리기, 구조화된 도구 출력을 갖춘 기능 도구를 설명합니다.² Anthropic의 도구 사용 문서는 Claude가 JSON Schema 입력을 통해 클라이언트 측 도구와 외부 기능을 호출하는 방식을 설명합니다.³ 에이전트는 검색, 캘린더 업데이트, 셸 명령, 데이터베이스 쿼리에 쓰는 것과 같은 도구 패턴으로 모델 예측을 요청할 수 있습니다.

팀이 이 분리를 건너뛰면 핵심 실패 모드가 나타납니다. LLM이 답을 만들 수 있다는 이유로 추정값을 요청합니다. 답은 빠르게 도착합니다. 문장은 그럴듯합니다. 인터페이스에는 그 숫자가 적합된 추정기가 아니라 패턴 완성에서 나왔다는 단서가 보이지 않습니다.

이것은 약한 계약입니다. 사용자는 무엇이 결과를 만들었는지 알 수 없습니다. 검토자는 모델 버전이나 입력 특징을 살펴볼 수 없습니다. 운영자는 호출을 재현할 수 없습니다. 제품은 왜 답이 바뀌었는지 설명할 수 없습니다.

증거 관문이 여기에도 적용됩니다. 확신은 증거가 아닙니다. 모델 호출은 증거를 만들 수 있습니다. 문장으로 만든 추측은 보통 그렇지 못합니다.

MLAT 패턴은 무엇을 더하나요?

MLAT는 Machine Learning as a Tool의 약자입니다. 이 논문은 대화에 정량적 추정이 필요할 때 LLM 에이전트가 호출할 수 있는 일급 도구로 학습된 ML 모델을 배치합니다.¹

논문의 파일럿 시스템인 PitchCraft는 두 에이전트를 사용합니다. 리서치 에이전트는 병렬 도구 호출로 잠재 고객 맥락을 수집합니다. 초안 에이전트는 XGBoost 가격 책정 모델을 호출한 뒤 구조화된 출력으로 제안서를 작성합니다.¹ ML 모델은 가격 책정을 처리합니다. LLM은 맥락, 조립, 설명을 처리합니다.

이 분리는 두 가지 나쁜 설계를 피하게 해주기 때문에 중요합니다.

에이전트도 여전히 중요합니다. 가격 책정 입력이 불완전한지 판단할 수 있습니다. 사용자에게 누락된 필드를 물어볼 수 있습니다. 모델을 호출하기 전에 검색이나 CRM 도구를 호출할 수 있습니다. 추정값이 자신의 권위가 아니라 모델에서 나왔다는 점을 설명할 수 있습니다.

이것이 올바른 역할 분담입니다. LLM은 조율하고, 적합된 모델은 예측합니다.

모델 도구는 무엇을 반환해야 할까요?

모델 도구는 숫자 하나만 던져주면 안 됩니다. 진지한 모델 도구는 증거 객체를 반환해야 합니다.

이 출력 형태는 모델 도구를 에이전트 실행 추적 기록은 실행 환경 계약입니다와 호환되게 합니다. 에이전트가 가격 책정 모델을 호출했다면 추적 기록에 모델 호출이 보여야 합니다. 에이전트가 모델을 건너뛰고 숫자를 작성했다면 추적 기록에서 그 부재가 분명히 드러나야 합니다.

같은 논리는 검토 패킷이 새로운 최종 답변입니다에도 적용됩니다. 가격만 담긴 최종 답변은 약합니다. 모델 호출 기록, 모델 버전, 특징 스냅샷, 신뢰 메모가 함께 있는 최종 답변은 검토자가 살펴볼 대상을 제공합니다.

모델 등록부는 어디에 들어맞나요?

도구로 감싸는 일은 MLOps를 대체하지 않습니다. MLOps를 에이전트 실행 환경에 노출합니다.

MLflow의 모델 등록부 문서는 모델의 계보, 버전 관리, 별칭, 메타데이터 태그, 수명 주기 정보를 설명합니다.⁴ 이 등록부 계층은 중요합니다. 플랫폼이 애초에 버전을 추적해야 에이전트 작업 흐름도 모델 버전을 인용할 수 있기 때문입니다.

Scikit-learn의 모델 영속화 문서는 서빙 측면에서 관련된 지점을 짚습니다. 영속화 선택에는 보안과 이식성의 트레이드오프가 따르며, ONNX는 Python 환경 없이도 모델을 서빙할 수 있지만 pickle 기반 경로는 소스에 대한 신뢰가 필요합니다.⁵ 모델 도구는 에이전트가 예측을 요청했다는 이유만으로 안전하지 않은 모델 산출물을 몰래 끼워 넣으면 안 됩니다.

최소 운영 스택은 다음과 같습니다.

팀들은 이런 계층을 predict라는 하나의 엔드포인트로 뭉개는 경우가 많습니다. 데모에서는 이 지름길이 통합니다. 하지만 에이전트가 예측을 고객 이메일, 영업 제안서, 인수 심사 메모, 인프라 계획, 의료 분류 초안에 이어 붙이기 시작하면 실패합니다.

제품에는 마법 같은 엔드포인트가 아니라 모델 계약이 필요합니다.

제품은 모델 출력을 어떻게 보여줘야 할까요?

UI는 답이 모델 도구에서 나왔을 때 사용자에게 알려야 합니다.

나쁜 인터페이스 문구는 출처를 숨깁니다.

더 나은 문구는 생성 경로를 명시합니다.

이 구분은 사용자의 존엄을 지킵니다. 사용자는 어떤 숫자가 검증된 모델, 모델 카드, 비즈니스 규칙, 언어 모델 완성 중 어디에서 나왔는지 추측할 필요가 없어야 합니다. 에이전트형 설계는 제어 화면 설계입니다는 에이전트 제품에 감독과 제어를 위한 화면이 필요하다고 주장합니다. 모델 출처도 그런 화면 중 하나입니다.

모델 카드는 문서화 계층에서 같은 문제를 돕습니다. Model Cards 논문은 모델 특성, 의도된 사용, 지표, 평가 맥락을 구조화해 보고하는 방식을 제안합니다.⁶ 에이전트 인터페이스는 이 아이디어를 실행 시점에 빌려올 수 있습니다. 모든 모델 답변은 사용자나 검토자가 모델이 어떤 종류의 주장을 했는지 이해할 수 있을 만큼 충분한 맥락을 담아야 합니다.

에이전트는 무엇을 거부해야 할까요?

모델을 인식하는 에이전트는 몇 가지 매혹적인 지름길을 거부해야 합니다.

모델 도구를 사용할 수 없을 때 모델 출력을 지어내는 일을 거부해야 합니다. 가격 책정 모델이 실패했다고 말할 수 있습니다. 사용자가 사람이 표시한 대략적인 추정값을 원하는지 물어볼 수 있습니다. 하지만 모델을 조용히 대체해서는 안 됩니다.

증거 없이 모델의 적용 범위를 넓히는 일을 거부해야 합니다. 중견 SaaS 데이터로 학습된 이탈 모델은 프롬프트가 정중하게 요청했다는 이유만으로 보편적인 사업 건강도 예언자가 되어서는 안 됩니다.

불확실성을 숨기는 일을 거부해야 합니다. 모델이 구간을 반환한다면, 제품에 명확한 표시 규칙이 없는 한 답변이 그것을 확신에 찬 단일 숫자로 접어 넣어서는 안 됩니다.

빠졌거나 조작된 특징으로 모델 도구를 호출하는 일을 거부해야 합니다. 에이전트는 입력을 수집하고, 후속 질문을 하고, 필드를 알 수 없음으로 표시할 수 있습니다. 편리한 허구로 특징 벡터를 채우면 안 됩니다.

모델 권위를 행동 권한으로 취급하는 일을 거부해야 합니다. 모델은 사기 위험을 추정할 수 있습니다. 그렇다고 에이전트가 계정을 동결할 수 있다는 뜻은 아닙니다. 행동에는 여전히 에이전트 키에는 위험 예산이 필요합니다의 범위 제한 키 규율이 필요합니다.

결정 규칙

에이전트 작업 흐름을 만들 때는 다음 규칙을 사용하세요.

이 규칙은 LLM에게 가치 있는 일을 주면서도, 다른 모든 시스템을 흉내 내게 만들지는 않습니다. LLM은 작업 흐름을 조율하고, 출력을 설명하고, 메시지를 초안 작성하고, 더 나은 질문을 던질 수 있습니다. 하지만 유창하게 말한다는 이유만으로 가격 책정 모델, 위험 모델, 사기 모델, 순위 모델, 정책 엔진이 될 수는 없습니다.

최고의 에이전트 제품은 하나의 모델에게 회사 전체인 척하라고 요구하지 않을 것입니다. 각 시스템이 증명할 수 있는 일을 맡는 도구 인터페이스를 만들 것입니다.

FAQ

이것은 전통적인 머신러닝 모델에만 해당하나요?

아닙니다. 같은 패턴은 전문화된 추정기나 점수화 시스템 전반에 적용됩니다. gradient-boosted 모델, 분류기, 순위 시스템, 예측 모델, 규칙 엔진, 검색 점수화기, 도메인 특화 감지기가 모두 포함됩니다. 핵심은 알고리즘이 아닙니다. 핵심은 출력 주변의 계약입니다.

왜 LLM이 직접 추정하게 두면 안 되나요?

때로는 거친 정성적 추정으로 충분합니다. 제품은 그 점을 분명히 말해야 합니다. 사용자가 가격, 위험 점수, 예측, 자격 결정을 필요로 한다면 답은 추적 가능한 입력과 한계를 갖춘 검증된 모델 또는 규칙 경로에서 나와야 합니다.

모델 도구를 쓰면 답이 자동으로 맞아지나요?

아닙니다. 모델 도구도 낡았거나, 편향되었거나, 보정이 잘못되었거나, 오용되었거나, 유효 범위를 벗어날 수 있습니다. 모델 도구는 살펴볼 수 있는 정도를 높입니다. 평가, 모니터링, 사람의 검토가 필요하다는 사실을 없애지는 않습니다.

최소한의 실행 가능한 모델 도구 계약은 무엇인가요?

입력 스키마, 출력 스키마, 모델 버전, 예측값, 신뢰 또는 단서, 오류 형태, 제한 시간, 추적 ID로 시작하세요. 모델이 돈, 접근 권한, 안전, 고객 대상 결정을 좌우한다면 특징 이름, 등록부 링크, 모델 카드 참조, 보정 메모를 추가하세요.

이것은 에이전트 UX를 어떻게 바꾸나요?

인터페이스는 중요한 출력의 출처를 표시해야 합니다. 사용자는 답이 모델 호출, 검색된 문서, 비즈니스 규칙, 사람의 승인, LLM 종합 중 어디에서 왔는지 볼 수 있어야 합니다. 그 출처는 답에 부여할 신뢰 수준을 바꿉니다.

참고 문헌