모델을 고르기 전에 측정 장치부터 만든다
Gabe Pereyra가 제시한 순서는 보통의 AI 도입 순서와 반대다. 어떤 모델을 쓸지, fine-tuning을 할지, GPU를 얼마나 살지부터 묻지 않는다. 먼저 회사가 잘하고 싶은 실제 업무를 benchmark로 고정한다. 그는 좋은 benchmark가 없으면 모델을 훈련할 수도, 프로덕션에 서빙할 이유도 없다고 말한다.
Harvey는 법률 업무를 한 덩어리로 보지 않았다. 대형 로펌의 어소시에이트가 수행하는 업무를 분류한 Legal Agent Benchmark를 만들고, 사내 계약 협상을 다루는 contracting 데이터셋과 M&A 실사를 다루는 diligence 데이터셋을 이어서 만들었다. 발표에 따르면 가장 큰 가상 data room은 8천만 토큰에 달하고, 실사 데이터셋에는 모델 출력을 채점하는 단위 테스트가 1,000개 넘게 들어간다. 이 수치는 발표 2분 55초와 4분 44초에 나온 Harvey의 설명이다. 독립적인 성능 검증 수치로 읽어서는 안 된다.
핵심은 benchmark가 순위를 매기는 표에 그치지 않는다는 점이다. 입력 자료, 모델이 수행할 과제, 허용된 행동, 결과를 검사할 rubric과 테스트를 함께 묶어야 비로소 모델을 개선할 목표가 생긴다. 모델이 바뀌어도 이 측정 장치는 회사에 남는다.
고객 데이터를 못 쓰기 때문에 rubric에서 거꾸로 data room을 만든다
법률 AI의 가장 큰 제약은 데이터 부족보다 권리와 기밀성이다. Harvey의 고객인 로펌과 기업이 다루는 계약, 이메일, 협상 기록은 특권 정보이거나 극도로 민감하다. Pereyra는 Harvey가 고객 데이터로 모델을 훈련하지 않는다고 명시한다. 공개된 최종 계약서는 찾을 수 있어도, 그 결론에 이르는 입력 자료와 협상 문맥은 공개돼 있지 않다.
Harvey가 찾은 해법은 도메인 전문가가 합성 데이터 생성을 이끄는 방식이다. 질의응답에서 Pereyra는 변호사인 Julio가 가짜 계약서 1만 건을 무작정 만드는 대신 rubric부터 설계했다고 설명한다. 어떤 계약끼리 맞지 않는지, 무엇이 빠졌는지, 실사 메모가 반드시 찾아야 할 문제가 무엇인지 먼저 심는다. 그다음 그 조건을 만족하는 data room을 생성한다. 모델이 실사 메모를 쓰면 이미 심어 둔 문제를 제대로 찾았는지 검사할 수 있다.
이 방식은 합성 데이터를 현실의 대체물로 선언하지 않는다. Pereyra도 합성 데이터만으로 충분하지 않지만 시작점으로는 쓸 수 있다고 선을 긋는다. Mercor와 Snorkel 같은 파트너는 계약서를 더 현실적으로 만들고 데이터 생산을 확장하는 데 쓰인다. 도메인 전문가는 문제 구조와 채점 기준을, 모델과 데이터 파트너는 대규모 생성을 맡는다.
benchmark를 공개하면 결함도 함께 드러난다
Harvey는 일부 benchmark와 데이터셋을 공개했다. 회사 고유 자산을 지키려는 전략과 모순처럼 보이지만, 목적이 다르다. 공개 benchmark는 여러 연구팀이 같은 과제를 풀면서 오류와 애매한 기준을 찾아내는 검증 장치다. Pereyra는 ImageNet, CIFAR, MNIST가 널리 쓰였기 때문에 문제점도 빨리 드러났다고 회상하며, 데이터셋이 좋은지 알려면 많은 사람이 실제로 훈련해 봐야 한다고 말한다.
질의응답에서는 공개하지 않은 benchmark를 고객이 어떻게 믿겠느냐는 문제도 짚는다. 연구소들이 모델을 발표할 때 Harvey의 데이터셋으로 benchmark하기 시작하면, 고객은 법률 영역별 강점과 약점을 직접 비교할 수 있다. 그러나 공개 점수만으로 제품 적합성을 보장할 수는 없다. Pereyra는 모델이 benchmark에 과적합하거나, 높은 점수를 받아도 실제 제품에서는 이상하게 느껴질 수 있다고 인정한다.
공개 benchmark의 역할은 하나의 승자를 정하는 일이 아니다. 모델 공급자가 낸 주장에 외부에서 질문을 던질 공통 언어를 만들고, 프로덕션 테스트에서 무엇을 더 확인해야 하는지 드러내는 일이다.
왜 지금은 작은 회사도 post-training을 시도할 수 있을까
Pereyra는 과거에는 회사가 별도로 튜닝한 이점이 다음 사전학습 모델에 금세 흡수됐다고 설명한다. 범용 모델 자체의 발전이 워낙 빨랐기 때문에, 특화 학습을 유지하는 비용에 비해 우위가 오래가지 않았다는 것이다. 최근에는 강한 open-weight 기반 모델을 특정 업무에 맞춰 추가 학습하면 프런티어 모델과 경쟁할 수 있다는 판단으로 바뀌었다고 말한다. 05:58–06:34
여기에는 중요한 단서가 있다. 모든 분야에서 일반적인 프런티어 지능을 얻었다는 주장이 아니다. Harvey처럼 목표 업무가 구체적일 때 경쟁력이 생긴다는 뜻이다. 따라서 자체 학습의 경제성도 회사별 benchmark와 실제 서비스 조건에서 판단해야 한다. 더 강한 범용 모델이 나왔을 때에도 특화 모델의 품질과 비용상 이점이 남는지 계속 비교해야 한다.
한 연구 파트너를 고르지 않고 연구 포트폴리오를 만든다
benchmark와 데이터가 생기면 다음 선택은 모든 인프라를 직접 만드는 것이 아니다. Pereyra는 처음에는 post-training 경험과 훈련 인프라를 가진 neolab과 협업하라고 권한다. 파트너와 함께해도 성능이 좋아지지 않는다면 데이터셋 자체에 문제가 있을 가능성을 먼저 의심할 수 있기 때문이다.
Harvey는 Fireworks, Baseten, Engram, Trajectory, Applied Compute와 서로 다른 과제를 진행했다고 설명한다. 여러 곳과 일하는 이유는 단순한 공급자 분산이 아니다. 내부 팀과 한 파트너가 처리할 수 있는 연구량에는 한계가 있고, 각 neolab이 서로 다른 모델과 연구 가설에 투자하기 때문이다. 많은 곳과 협업할수록 더 많이 배운다는 설명은 연구 파트너를 외주업체가 아니라 병렬 실험 경로로 본다는 뜻이다.
동시에 내부 역량도 축적한다. Tinker 같은 API와 Fireworks, Baseten의 인프라를 이용하면 훈련 스택과 서빙 스택을 처음부터 만들지 않고도 post-training을 직접 시도할 수 있다. 초기에는 외부 전문성을 빌리되, 실험 결과와 benchmark 운용 능력은 회사 안에 남기는 구조다.
질의응답에서는 인프라가 채용 문제를 바꾸는 이유까지 설명한다. 예전에는 post-training 연구뿐 아니라 훈련과 서빙 인프라를 모두 만들 수 있는 드문 인재가 필요했다. 이제 관리형 API와 인프라를 쓰면 한 사람이 그 모든 능력을 갖출 필요가 줄어든다. Pereyra는 이 변화가 채용 가능한 인재의 범위를 넓혔다고 본다. 연구 인력을 구하기 쉬워졌다는 보편적 통계가 아니라, 맡겨야 할 업무가 달라졌다는 조직 설계의 설명이다. 17:57–18:35
post-training보다 먼저 필요한 것은 모델 교체와 퇴출의 관문이다
모델을 잘 훈련해도 제품에 안전하게 넣을 수 없다면 연구는 멈춘다. Harvey는 60개국에서 여러 제품을 운영하고, 고객마다 모델 선호가 다르며, SLA를 지키기 위해 제공사 간 fallback도 둔다고 설명한다. 이 복잡한 서빙 행렬은 자체 모델만을 위한 별도 경로가 아니다. 폐쇄형 모델, open-weight 모델, post-training 모델 모두 같은 관문을 통과한다.
프로덕션 이전에는 Legal Agent Benchmark 같은 범용 자동 eval, 사람의 side-by-side 평가, 제품별 핵심 사용자 여정과 자동 테스트, 사람의 제품 테스트를 함께 본다. 여기에 비용, 지연 시간, 지역 가용성 같은 운영 조건이 붙는다. 범용 성능이 좋아도 특정 제품 영역에는 맞지 않을 수 있기 때문이다.
배포 뒤에는 A/B test, 참여도, uptime, token efficiency, 제품 피드백을 본다. Pereyra가 제품 피드백을 "화난 고객의 이메일"이라고 부르는 대목은 평가가 숫자로 끝나지 않는다는 점을 압축한다. 자체 모델을 갖는다는 말은 가중치 파일을 보유한다는 뜻보다, 모델을 넣고 관찰하고 빼는 운영 능력을 갖춘다는 뜻에 가깝다.
가장 작은 전환부터 시작해 routing 근육을 만든다
Harvey의 플레이북에서 post-training은 첫 실행 항목이 아니다. 먼저 제품 안에서 가장 큰 모델이 필요 없는 지점을 찾는다. Pereyra는 인용 생성 기능을 open-weight 모델로 단순 교체할 수 있는 예를 든다. 이 단계에서 팀은 품질을 비교하고, 비용과 지연 시간을 재고, 폐쇄형 모델 옆에 다른 모델을 서빙하는 법을 배운다.
다음은 model routing이다. 모든 질의를 한 모델로 보내는 대신 일부 질의만 더 작거나 특화된 모델로 보낸다. 이 두 단계를 거치면 post-training 모델을 투입하기 전에도 모델 포트폴리오를 운영할 수 있다. 어느 과제에 어느 정도의 지능이 필요한지, fallback은 언제 작동해야 하는지, 비용 절감이 제품 지표를 해치지 않는지를 실제 트래픽에서 확인할 수 있다.
이 작은 전환은 비용 절감 프로젝트 이상의 의미가 있다. 같은 요청을 여러 모델에 보내 비교할 수 있고, 특정 모델이 실패했을 때 대체 경로가 실제로 작동하는지 확인하며, 지역별 가용성과 latency 차이를 제품 수준에서 측정할 수 있다. 모델마다 잘하는 법률 영역이 다르다는 사실을 운영 규칙으로 바꾸는 단계다. post-training 모델도 이 포트폴리오의 한 항목으로 들어가야 기존 모델과 같은 기준으로 평가받는다.
그 뒤에야 사용자 테스트와 제품 운영에서 얻은 신호를 다음 데이터셋과 모델 개선에 연결한다. Harvey는 고객 데이터 자체를 훈련에 쓰는 것이 아니라고 다시 선을 긋는다. feedback flywheel이라는 표현이 데이터 권리와 목적 제한을 지워 주지는 않는다. 어떤 신호를 어떤 근거로 수집하고 어디까지 재사용할 수 있는지 별도로 설계해야 한다.
기술의 병목은 한 곳에 있지 않고, 최종 제품은 조직 운영에 가까워진다
질의응답에서 누군가는 데이터 생성, 환경, 알고리즘, 인프라 가운데 어디가 주된 병목인지 묻는다. Pereyra의 답은 한 요소로 환원할 수 없다는 것이다. Harvey가 먼저 폐쇄형 모델로 실제 제품과 모니터링 체계를 운영했기 때문에, 새 모델이 실패했을 때 benchmark, 제품 테스트, 데이터 분포, 서빙 중 어디를 의심할지 비교할 기준이 생겼다. benchmark가 나쁘면 다음 단계로 갈 가능성이 낮지만, benchmark를 통과해도 제품에서 실패할 수 있다.
또 다른 한계는 합성 데이터와 실제 사용 분포의 차이다. 고객 데이터를 볼 수 없으면 아무리 현실적인 data room을 만들어도 간극이 남는다. 공개 benchmark가 그 간극을 자동으로 없애지도 않는다. 발표는 이 문제를 완전히 해결했다고 주장하지 않는다.
마지막에 Pereyra는 법률 AI의 목표를 문서 한 단락을 더 잘 쓰는 일보다 훨씬 크게 설명한다. 로펌은 고객 1만 곳의 수많은 사건을 운영하고, 한 사건은 6개월 동안 20명이나 30명이 협업할 수 있다. 조직 수준에서는 이런 프로젝트가 1,000개가 된다. 사람과 agent, 외부 관계자를 함께 조율하는 프로젝트 관리 문제로 바뀌는 셈이다. 범용 모델이 따라오기 어려운 지점은 문장 생성보다 이 도메인 운영 구조에 있다.
Harvey 발표를 실행 순서로 다시 쓰면
이 발표에서 배울 수 있는 순서는 일곱 단계다. 실제 업무를 분해해 benchmark와 rubric을 만들고, 권리를 지킬 수 있는 합성 입력을 도메인 전문가가 설계하며, 외부 사용자가 결함을 찾을 수 있는 범위는 공개한다. 그다음 여러 연구 파트너와 병렬로 post-training을 시험하되 결과와 판단 기준을 내부에 축적한다. 새 모델은 기존 모델과 같은 pre-production 관문을 통과시키고, 작은 open-weight 교체와 routing으로 운영 역량을 먼저 만든다. 마지막으로 허용된 피드백 신호만 다음 데이터셋에 반영한다.
각 단계에는 멈춤 조건도 있다. 현실적인 업무와 채점 기준을 정의하지 못했다면 훈련으로 넘어갈 이유가 없다. 합성 입력의 분포가 실제 업무와 다르다면 점수 상승을 제품 성능으로 해석할 수 없다. benchmark에서는 좋지만 핵심 사용자 여정에서 나쁘다면 배포하지 않는다. 배포 뒤 비용이나 지연 시간, 사용자 피드백이 악화되면 모델을 유지할 이유도 없다. 이 조건들이 있어야 여러 파트너와 모델을 시험하는 일이 연구 포트폴리오가 되며, 그렇지 않으면 서로 다른 데모를 모으는 일에 그친다.
이 순서가 중요한 이유는 모델 소유보다 평가와 운영 소유가 먼저이기 때문이다. 좋은 데이터셋이 있어도 verifier가 허술하면 모델은 잘못된 목표를 학습한다. 좋은 모델이 있어도 서빙, fallback, 관찰, 퇴출 절차가 없으면 제품이 되지 않는다. 강한 공개 모델이 새로 나와도 회사의 업무 기준이 없다면 다시 공급자의 데모를 따라가게 된다.
Pereyra는 Moneyball의 문장을 빌려 작은 예산과 작은 팀으로 판을 바꾸자고 끝맺는다. 그러나 발표 전체가 보여 주는 실제 방법은 영웅적인 한 번의 훈련이 아니다. 측정 장치를 먼저 만들고, 권리 경계를 지키며 데이터를 만들고, 여러 실험을 같은 제품 관문에 통과시키는 반복 가능한 연구 운영이다.