저희 텍스트-투-쿼리 에이전트는 프론티어 모델에서 45초가 걸리던 작업을 GLM 5.3 Flash 에서 2초 만에 처리하며, 동일한 정확도에 1/20 비용을 달성했습니다.
Conversion 에서 최근 진행한 AI 작업의 대부분은 일반 마케팅 인텔리전스에 초점을 맞추고 있습니다.
마케팅 자동화 팀은 계정 조사, 잠재 고객 구축, 캠페인 기획, 콘텐츠 작성, 성과 데이터 분석 등 다양한 시스템에서 폭넓은 작업을 수행합니다. 저희는 이러한 워크플로 전반을 추론하고 숙련된 마케터가 사용하는 것과 동일한 도구를 활용할 수 있는 에이전트를 구축해 왔습니다.
이러한 시스템은 유능하고 범용적인 모델의 혜택을 받습니다. 작업은 개방형이며, 작업을 빠르게 완료하는 것보다 올바른 판단이 더 중요한 경우가 많습니다.
하지만 저희에게는 더 작고 집중된 AI 기능에 대한 백로그도 있었습니다. 그중 하나는 자연어 필터였습니다. 사용자가 일반 영어로 잠재 고객을 설명하면, Conversion 의 기존 명령문 빌더에서 해당 설명을 검사하고 편집할 수 있는 필터로 변환하는 기능입니다. (Conversion 에서 필터는 명령문이라고 합니다.)
처음에는 이것이 간단한 구조화된 생성 작업처럼 보였습니다. 모델에 사용 가능한 필드를 제공하고, 출력 형식을 설명한 다음, JSON 을 생성하도록 요청하는 것이었습니다. 그러나 실제로는 훨씬 더 어려운 작업으로 판명되었습니다.
GLM 5.3 Flash 를 사용하여 5초 이내에 생성된 복합 명령문.
다음 예시를 살펴보겠습니다.
지난 30일 동안 데모 양식을 한 번 이상 제출하고, 50,000 달러 이상의 진행 중인 기회가 있는 소프트웨어 회사에 재직 중인 연락처를 찾으십시오.
이를 위해서는 시스템이 다음을 수행해야 합니다.
- 사용자가 "데모 양식"이라고 말한 특정 양식을 찾습니다.
- 회사의 업종을 나타내는 필드를 확인합니다.
- 해당 작업 공간에서 "소프트웨어"를 어떻게 표현하는지 학습합니다. 즉, 추측하는 대신 해당 필드에 실제로 저장된 값을 확인해야 합니다.
- 연락처에서 해당 회사로, 그리고 해당 회사의 기회로 이동합니다.
- "진행 중"과 "50,000 달러 이상"이 동일한 기회에 적용되는지 확인합니다.
- 상대적 이벤트 기간을 적용합니다.
또한 리서치 에이전트가 아닌 필터 인터페이스처럼 느껴질 수 있을 만큼 빠르게 이 모든 작업을 수행해야 했습니다.
작은 프롬프트 엔지니어링 작업처럼 보였던 것이 제약된 텍스트-투-쿼리 문제로 바뀌었습니다. 이를 해결하려면 도구 사용 에이전트, 중간 표현(IR), 결정론적 컴파일러, 그리고 의미론적 벤치마크가 필요했습니다.
저희는 Claude Opus 5, Kimi K3, GLM 5.3 Flash, 그리고 오늘 아침에 출시된 Gemini 3.8 Flash 를 포함한 8개의 모델을 결과 벤치마크인 Statement Bench 에서 실행했습니다. 결과는 아래와 같습니다.
에이전트에 도구 제공하기
위 요청에 답변하는 데 필요한 대부분의 정보는 고객 환경에 따라 다릅니다. 단일 작업 공간에는 수억 개의 과거 필드 값과 자산 및 객체가 포함될 수 있습니다. 명백한 이유로, 이 모든 정보를 하나의 프롬프트에 담을 수는 없었습니다.
첫 번째로 유용했던 아키텍처 결정은 이 문제를 일반적인 구조화된 생성으로 취급하는 것을 중단한 것입니다. 대신, 모델은 소수의 도구 세트를 받습니다. 필드를 검색하고, 과거 값을 조사하며, 양식, 캠페인, 이메일, 잠재 고객과 같은 비즈니스별 자산을 확인할 수 있습니다. 요청에 필요한 경우에만 이러한 도구를 사용합니다.
이 검색 인프라의 대부분은 Conversion 의 모든 레코드에 대한 텍스트 및 의미론적 검색을 제공하는 최근 Global Search 작업에서 비롯되었습니다. 이에 대한 자세한 내용은 곧 공유할 예정입니다!
기본 흐름은 다음과 같습니다.
1자연어 요청2 |3 v4 도구 사용 에이전트 <-----------------+5 / | \ |6필드 자산 관계 | 이유를 포함한 거부7 \ | / |8 v |9 제약된 IR |10 | |11 v |12 검증기 및 컴파일러 -------------------+13 |14 v15 프로덕션 명령문
이렇게 하면 초기 컨텍스트가 작게 유지됩니다. 또한 실패 원인을 훨씬 쉽게 이해할 수 있습니다. 명령문이 잘못된 경우, 에이전트가 잘못된 자산을 찾았는지, 잘못된 필드를 선택했는지, 관계를 오해했는지, 올바른 아이디어를 잘못 표현했는지, 또는 컴파일러에 버그가 있는지 확인할 수 있습니다. 이러한 구분은 이후 평가 루프에서 중요해졌습니다.
더 작은 언어 만들기
도구 사용은 컨텍스트 문제를 해결했습니다. 그러나 지연 시간 문제는 해결하지 못했습니다.
초기 피드백에서 얻은 한 가지 교훈: 사용자는 채팅보다 목적에 맞게 구축된 인터페이스에서 훨씬 더 적은 지연 시간을 용납합니다.
이는 더 넓은 역설을 지적합니다. 우리는 시스템이 작업을 수행하는 데 얼마나 어려운지가 아니라, 우리에게 작업이 얼마나 어렵게 느껴지는지에 따라 지연 시간 기대치를 설정합니다. 콘텐츠 작성은 작업이 눈에 보이기 때문에 어렵게 느껴집니다. 필터를 설명하는 것은 우리의 마음이 컨텍스트, 엔터티, 관계 및 의도를 조용히 해결하기 때문에 간단하게 느껴집니다. 모델의 경우, 이러한 숨겨진 가정을 재구성하는 것이 작업입니다. 사용자가 인지하는 작업이 적을수록 시스템이 이를 수행할 시간도 줄어듭니다.
초기 피드백을 바탕으로 두 가지 목표를 설정했습니다: 95% 이상의 정확도와 일반적인 쿼리에 대한 약 5초의 응답 시간.
Conversion 은 표현력이 풍부한 내부 쿼리 언어를 가지고 있습니다. 초기 테스트에서 프로덕션 형식을 직접 사용했을 때, Claude Opus 와 같은 가장 큰 모델만이 안정적으로 생성할 수 있었습니다. 간단한 명령문조차 약 45초가 걸렸습니다.
시각적 명령문 빌더는 전체 언어의 하위 집합만 노출합니다. 저희는 해당 하위 집합에 대해 더 작고 에이전트 친화적인 중간 표현을 만들었습니다. 더 작은 모델이 더 적은 토큰을 사용하여 이를 생성할 수 있는 반면, 결정론적 컴파일러가 전체 프로덕션 형식을 처리했습니다.
다음 명령문을 고려해 보십시오.
직함에 "Director"가 포함됩니다.
원래 프로덕션 명령문은 다음과 같습니다.
1{2 "type": "LOGICAL",3 "version": 1,4 "logical": {5 "operator": "OR",6 "operands": [7 {8 "type": "LOGICAL",9 "version": 1,10 "logical": {11 "operator": "AND",12 "operands": [13 {14 "type": "VARIABLE",15 "version": 1,16 "variable": {17 "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",18 "where": {19 "type": "LOGICAL",20 "version": 1,21 "logical": {22 "operator": "AND",23 "operands": [24 {25 "type": "LOGICAL",26 "version": 1,27 "logical": {28 "operator": "CONTAINS",29 "operands": [30 {31 "type": "ATTRIBUTE",32 "version": 1,33 "attribute": {34 "name": "value"35 }36 },37 {38 "type": "CONSTANT",39 "version": 1,40 "constant": {41 "value": "Director"42 }43 }44 ]45 }46 }47 ]48 }49 }50 }51 }52 ]53 }54 }55 ]56 }57}
동일한 필터의 모델 지향 표현은 다음과 같습니다.
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
IR 은 이미 여러 세대를 거쳤으며, 최신 버전은 더 작은 모델이 이전 버전에서 실패하는 것을 관찰하여 형성되었습니다. 한 가지 큰 개선 사항은 더 나은 동일 레코드 의미론(스키마 검증으로는 포착할 수 없는 것)을 도입한 것입니다.
1{2 "related": "OPPORTUNITY",3 "all": [4 { "field": "<stage uuid>", "op": "equals", "value": "Closed Won" },5 { "field": "<amount uuid>", "op": "gt", "value": 100000 }6 ]7}
모델과 코드 간의 이러한 분할은 몇 가지 유용한 속성을 제공했습니다.
- 지원되지 않는 명령문은 표현하기 어렵습니다.
- 동일 레코드 관계 의미론이 표시됩니다.
- 필드 및 관계 참조를 검증할 수 있습니다.
- 컴파일러는 모델과 독립적으로 테스트할 수 있습니다.
- 생성된 명령문은 기존 UI 에서 계속 편집할 수 있습니다.
IR 은 궁극적으로 모델의 작업을 축소합니다. 에이전트는 사용자의 의도를 해결하고 제약된 계획을 생성합니다. 코드는 프로덕션 형식을 처리합니다.
의미론적 벤치마크 구축
출력이 완전히 유효하더라도 여전히 잘못될 수 있습니다. 다음 요청을 예로 들어 보겠습니다.
10만 달러 이상의 성사된 기회가 있는 회사의 연락처.
연락처는 회사에 속하고, 회사는 여러 기회를 가질 수 있습니다. 이 필터를 일치시키려면 관계(연락처에서 회사로, 회사에서 기회로)를 탐색하고 두 가지 조건(딜이 성사되었는지, 딜 가치가 10만 달러 이상인지)을 확인해야 합니다.
어려운 점은 이러한 조건이 동일한 기회에 적용되어야 한다는 것입니다. 만약 독립적으로 확인된다면, 성사된 2만 달러 딜과 진행 중인 15만 달러 딜이 있는 회사는 두 조건을 모두 충족합니다. 각 조건이 하나씩 일치하기 때문입니다. 스키마 검증으로는 이를 절대 포착할 수 없습니다.
이와 같은 예시가 몇 번 통과되면, 프롬프트를 편집할 때 이들을 회귀시킬 위험이 있었습니다. 우리는 유효성뿐만 아니라 의미를 확인하고, 무언가 변경될 때마다 이를 확인할 수 있는 방법이 필요했습니다.
저희는 제품의 동작을 기반으로 Statement Bench 를 구축했으며, 이는 고객이 이전에 구축한 익명화된 잠재 고객 패턴에서 파생되었습니다. 현재 스위트는 일반 필드 조건, 이벤트, 상대 및 달력 시간 기간, 관계, 복합 쿼리 등 15개 범주에 걸쳐 100개의 케이스를 보유하고 있습니다.
각 케이스는 실제 작업 공간 샌드박스에 대해 실행됩니다. 에이전트는 프로덕션에서 받는 것과 동일한 데이터와 도구를 받습니다.
평가자는 여러 계층을 확인합니다.
- 에이전트가 명령문을 반환했는가?
- IR 이 해당 스키마를 충족하는가?
- 참조된 필드와 관계가 존재하는가?
- 명령문이 컴파일되어 프로덕션 검증을 통과할 수 있는가?
- 요청된 의미를 나타내는가?
- 필요한 모델 단계, 도구 호출, 토큰 및 거부된 제출 수는 얼마인가?
다섯 번째가 가장 흥미롭습니다. 유효성이 의미론적 동등성을 보장하지 않기 때문입니다.
의미론적 검사는 컴파일된 명령문을 읽고, "단계와 금액을 모두 포함하는 하나의 기회 조건", "유형이 열림이 아닌 클릭인 이메일 이벤트", 또는 "사용자 정의 캠페인이 아닌 웨비나 조건"과 같은 것을 확인합니다.
평가 기반 최적화 루프 실행
벤치마크는 기능에 대한 작업 방식을 변화시켰습니다. 코딩 에이전트에게 "프롬프트 개선" 또는 "새로운 IR 구현"을 요청하는 대신, 개선에 대한 실행 가능한 정의를 제공할 수 있었습니다.
루프는 다음과 같았습니다.
- 벤치마크 실행
- 근본 원인별로 실패 그룹화
- 에이전트의 도구 궤적 및 제출된 IR 검사
- 프롬프트, 도구, 검증기 또는 컴파일러 변경
- 전체 벤치마크 다시 실행
- 회귀를 도입하지 않고 시스템을 개선하는 경우에만 변경 사항 유지
코딩 에이전트는 벤치마크를 사용하여 모델을 비교하고, IR 을 실험하고, 도구 설명을 개선하고, 프롬프트를 자율적으로 개선할 수 있었습니다. 모든 변경 후에 전체 스위트를 실행하는 것은 개별 실패에 과적합되는 것을 방지했으며, 이를 확인하기 위해 추가로 50개의 케이스를 보류했습니다.
몇 가지 변경 사항이 결과를 가장 크게 개선했습니다.
- 경로, 유형 및 구조를 컴파일러로 이동. 첫 번째 IR 은 모델이 모든 관계를 명시적으로 작성하도록 했습니다: 연락처에서 회사로, 회사에서 기회로. 필드의 메타데이터는 이미 해당 경로를 암시하므로, 컴파일러가 이제 이를 추론합니다. 날짜, 유형 변환, 부정 배치 및 그룹 중첩에 대해서도 동일하게 수행했습니다. 규칙을 컴파일러로 이동하면 IR 이 단순화되고 스키마 오류가 줄어듭니다.
- 설명 및 수정 사항과 함께 거부. 모든 스키마 및 컴파일러 거부는 가능한 경우 대신 작성할 내용을 알려줍니다: "이 필드에서는 gt 를 부정할 수 없습니다. lte 를 사용하십시오", "campaign_list 에서 id 를 복사하십시오". 작은 모델은 한두 번의 재시도 내에 수렴하며, 프로덕션 모델은 요청 100개당 몇 개에서 거부됩니다.
- 작은 모델을 위한 프롬프트 구조화. 프롬프트를 재구성해도 정확도는 변하지 않았지만, 재시도 횟수를 절반으로 줄여 지연 시간을 직접적으로 개선했습니다. 이는 Anthropic 의 프롬프팅 모범 사례에서 영감을 받았습니다.
- 설명보다 예제 사용. 형식 참조에 두 개의 추가 예제를 추가하여 여러 단락의 설명으로도 해결되지 않았던 누락 클래스를 해결하여 거부된 제출을 대략 절반으로 줄였습니다.
- 완전한 컨텍스트를 제공하거나 전혀 제공하지 않음. 모델은 도구를 호출하기 전에 컨텍스트에 있는 것을 먼저 사용합니다. 컨텍스트에 부분적이거나 레이블이 지정되지 않은 필드 세트가 포함된 경우, 모델은 검색하는 대신 가장 가까운 필드를 사용하여 의미론적으로 잘못된 명령문을 생성했습니다. 부분 컨텍스트를 줄이고 도구 호출을 선호함으로써 빌드 속도를 높이고 입력 토큰을 5분의 1로 줄였습니다.
최종 프로덕션 구성인 GLM 5.3 Flash 는 모든 100개의 벤치마크 케이스를 완료했으며, 중간 지연 시간은 2.3 초, 95번째 백분위수는 7.1 초였습니다. 그리고 100개 중 97개가 의미론적으로 정확했습니다. 원래 프로덕션 형식 접근 방식과 비교하여, 간단한 필터는 약 45초에서 1초 조금 넘게, 비용은 1/20 로 개선되었습니다.
Statement Bench 에서 모델 비교
벤치마크는 또한 실제 작업에서 모델을 비교할 수 있는 방법을 제공했습니다.
2026 년 9 월 2일, 8개 모델에 대해 동일한 100개 케이스를 실행했습니다. 각 모델은 동일한 프롬프트, 도구, IR, 컴파일러 및 30초 요청 시간 제한을 받았습니다.
공급자 라우팅, 프롬프트 캐싱 및 임시 추론 부하는 모두 지연 시간에 영향을 미칩니다.
모델
유효한 빌드
의미론적으로 정확함
P50 지연 시간
P95 지연 시간
캐시 읽기
도구 호출
거부된 제출
요청 1,000건당 예상 비용
Claude Opus 5
100/100 (100%)
100/100 (100%)
3.16 초
8.53 초
91.1%
162
0
$27.51
GLM 5.2
100/100 (100%)
100/100 (100%)
4.38 초
13.02 초
93.5%
201
5
$14.94
Kimi K3
100/100 (100%)
100/100 (100%)
5.17 초
11.84 초
34.3%
157
0
$48.51
GLM 5.3 Flash
100/100 (100%)
97/100 (97%)
2.34 초
7.07 초
92.8%
163
2
$1.33
DeepSeek V4 Pro
96/100 (96%)
96/96 (100%)
5.53 초
24.31 초
47.8%
172
1
$12.00
Gemini 3.7 Flash
77/100 (77%)
77/77 (100%)
15.14 초
30.01 초
26.5%
228
1
$18.24
Gemini 3.8 Flash
76/100 (76%)
76/76 (100%)
14.29 초
30.01 초
35.4%
266
1
$27.44
DeepSeek V4 Flash
56/100 (56%)
55/56 (98%)
6.79 초
30.00 초
41.5%
100
1
$0.56
예상 비용은 2026 년 9 월 2일 각 공급자의 게시된 비프로모션 요율을 사용하여 관찰된 입력, 캐시된 입력 및 출력 토큰을 기준으로 한 시도된 요청 1,000건당 비용입니다. 캐시된 입력은 공급자가 게시하는 경우 게시된 캐시 읽기 요율로 청구되며, 그렇지 않은 경우 전체 입력 요율로 청구됩니다.
그림 1. 비용 대비 정확도. GLM 5.3 Flash 는 Claude Opus 5 비용의 약 20분의 1로 97%에 도달합니다.
그림 2. 지연 시간 분포, 중앙값 및 95번째 백분위수, P95 기준 정렬.
몇 가지 발견 사항이 눈에 띄었습니다.
모델 크기나 가격은 지연 시간을 예측하지 못했습니다. 가장 빠른 모델은 가장 작고 저렴했습니다. 두 번째로 빠른 모델은 가장 크고 비쌌습니다.
실패가 잘못된 답변에서 느린 답변으로 이동했습니다. 8개 모델 중 6개는 완료한 모든 명령문에서 의미론적으로 정확했습니다. 모델 간의 차이는 거의 전적으로 시간 제한 내에 완료된 요청 수에 있습니다. IR 및 프롬프트의 초기 반복에서 대부분의 소형 모델은 빌드 단계에서 50% 미만의 의미론적 정확도로 벤치마크에 실패했습니다.
추론 토큰이 도구 호출보다 중요합니다. Gemini 3.8 Flash 는 192,000 개의 출력 토큰 중 180,000 개를 추론에 사용했고 266번의 도구 호출을 했습니다. Claude Opus 5 는 추론에 813 개의 토큰을 사용했고 162번의 호출을 했으며 모든 케이스를 완료했습니다. Global Search 노력으로 각 도구 조회가 밀리초 범위로 줄어들었으므로, 남은 비용은 그 사이의 모델 턴입니다.
결론
모델은 모호성 해결에 능숙하고, 코드는 정밀성 강제에 능숙하며, 초기 실패의 대부분은 모델에게 두 가지를 모두 수행하도록 요청한 데서 비롯되었습니다. 이 에이전트를 구축하는 것은 각 부분을 둘 중 어느 것이 소유해야 하는지 결정하는 작업이었습니다. 텍스트-투-SQL 및 대부분의 다른 자연어 인터페이스에도 동일하게 적용될 것으로 예상합니다.
이러한 문제에 관심이 있으시면 연락 주십시오! 저희는 채용 중입니다.
