Seldon은 두 AI 작업에서 프런티어 모델보다 싸고 빨랐다

Seldon Functions는 데이터 파이프라인의 LLM 호출을 더 빠르고 저렴한 프로그램으로 컴파일하고, 사용자가 신뢰하는 모델과 비교해 결과를 검증한다. Seldon이 공개한 두 차례의 프로덕션 실험에서는 에이전트 추적 분석에서 비용을 5분의 1로 낮추면서 정확도와 속도를 높였고, 개인정보 식별에서는 LLM을 주 경로에서 없애 총비용을 약 8,000분의 1로 줄였다. 다만 개인정보 실험에서 단독 이름을 놓치는 등 정확도 저하도 있었다.

라우터는 모델을 고르지만 Seldon은 프로그램을 만든다는 것이 회사의 설명이다. 두 사례에서 원래 프롬프트를 GPT-5.6 Sol에 보내는 기준선과 Seldon의 대안을 같은 입력으로 비교했다. 두 프로그램 모두 새 입력을 주 경로에서 처리했고 대체 경로는 호출되지 않았다. 컴파일 비용은 약 15~17달러였으며, 회사 추산으로 약 950~2,300회 호출 뒤 손익분기점에 도달한다.

모델 ID를 바꾸는 방식으로 적용하며 나머지 코드는 바꾸지 않아도 된다고 Seldon은 설명한다.

- model="gpt-5.6-sol"
+ model="seldon/function/<FUNCTION_ID>@<REVISION_ID>"

기능과 실험 방식

프로덕션에서 반복되는 LLM 호출 가운데 상당수는 대화가 아니라 고정된 스키마의 JSON을 만드는 함수형 작업이라는 것이 Seldon의 설명이다. 회사는 이런 호출마다 프런티어 모델 비용을 내는 대신, 프롬프트·스키마·신뢰하는 기준 모델을 제공하면 대체 프로그램을 찾아 기준 모델과 비교할 수 있다고 말한다. 대안은 더 작은 LLM, GLiNER 같은 특화 모델, Jev 같은 결정 모델, 결정론적 코드 등을 조합한 다단계 파이프라인이다.

비교 보고서에는 기준 모델과 최대 세 대안을 나란히 놓고 품질, 치명적 실패, 비용, p50/p95 지연 시간, 대체 경로 비율과 커버리지를 표시한다. 사용자가 직접 선택하며 자동 활성화는 없다. 실행 중 출력 검증을 거치고 원래 호출을 대체 경로로 유지한다. 엔드포인트는 OpenAI 호환 방식이어서 OpenAI SDK, LiteLLM, LangChain, Vercel AI SDK를 바꾸지 않고 쓸 수 있다고 한다.

두 실험은 별도 스크립트로 만들고 프로덕션 api.seldon-ai.com에서 실제 모델과 실제 지갑 청구를 사용해 실행했다. 각 컴파일 함수는 보류 입력에서 GPT-5.6 Sol에 원래 프롬프트를 보내는 기준선과 맞붙었다. 정규식, Presidio + GLiNER, 직접 작성한 특징, LLM 요약 등 대안으로 고려할 도구도 시험했으며 실패 사례도 공개했다고 Seldon은 밝혔다.

추적 분석 실험은 PostHog의 LLM 추적 클러스터링 설명에서 영감을 얻었다. 개인정보 식별 실험은 Mercor처럼 기업 데이터를 라이선스하는 회사가 공개적으로 설명한 익명화 수요에서 착안했다. Seldon은 두 실험의 설정과 데이터를 직접 만들고 실행했으며, 두 회사는 실험에 관여하거나 이를 승인하지 않았다. 실험은 두 회사의 시스템을 측정·재현·평가하지 않는다.

두 실험의 비교 결과

첫 실험은 에이전트 추적 신호를 추출하는 작업이다. 기준선은 요청마다 gpt-5.6-sol과 원래 프롬프트를 썼고, Seldon 대안은 gpt-5.6-luna와 같은 프롬프트를 쓰며 Sol은 대체 경로로만 남겼다.

두 번째 실험은 개인정보 식별이다. 기준선은 Sol을 한 번 호출했고, Seldon 프로그램은 gliner2.5-multi-v1로 범위를 찾은 뒤 결정론적 단계 두 개를 수행했다. Sol은 대체 경로에만 있었다.

보류 보고서는 Seldon이 만든 합성 예시, 독립 평가자, 순차 실행 시간을 사용했다. 외부 시험은 프로덕션 게이트웨이를 거쳤으므로 네트워크와 게이트웨이 오버헤드가 지연 시간에 포함됐다. Seldon 비용은 실제 청구액이다. 외부 시험의 Sol 비용은 입력 토큰 100만 개당 $5, 출력 토큰 100만 개당 $30으로 계산한 추정치다. 두 기준선 모두 Seldon이 직접 실행한 Sol 호출이며, 어떤 수치도 PostHog나 Mercor 시스템을 설명하지 않는다.

Seldon은 추적 분석에서 결과가 달라진 모든 지표에서 기준선을 앞섰다고 정리했다. 개인정보 식별에서는 훨씬 저렴하고 여러 배 빠르며 모든 문서를 처리했지만, 기준선이 찾은 이름을 놓쳤다. 로컬 Presidio + GLiNER는 재현율이 더 높았다. 추적 결과는 뚜렷한 개선이지만 개인정보 결과는 선택 전에 확인해야 할 절충이라고 회사는 설명한다.

컴파일과 호출 절차

Seldon Functions의 수명 주기는 네 단계다. 사용자가 직접 활성화하기 전에는 아무 대안도 적용되지 않는다.

• 생성: 프롬프트, 입력·출력 JSON 스키마, 기준 모델을 올린다. 추적 데모의 계약은 {"text": "..."} → {intent, actions[], outcome, failure_signals[], evidence[]}다.
• 미리보기: 비용이 발생하며 상한이 적용된다. Seldon은 합성 예시를 만들고 기준 모델로 실행한 뒤 평가기를 추론해 예상 비용, 예상 시간, 사용 가능한 구성 요소를 제시한다. 서버가 상한을 적용하며 현재 최대치는 100달러다.
• 최적화: 완성된 프로그램을 대상으로 제한된 검색을 수행한다. 후보는 최대 64개, 단계는 16개, 학습 노드는 3개다. 구성 요소에는 더 작은 LLM(예: GPT-5.6 Luna), 특화 모델(fastino/gliner2.5-multi-v1은 범위와 레코드, typesafe/jev는 불리언·열거형·쌍 결정용), 결정론적 커널(정확한 범위 정렬, JSON 포인터 레코드 투영, 조회, 산술, 제약 검사), 선택적 대체 경로로서 기준 모델이 포함된다. 작은 검색 공간은 전수 검사하고, 큰 공간은 SMAC 랜덤 포리스트 베이지안 최적화로 전체 프로그램을 평가한다.
• 비교 및 활성화: 실행 결과는 기준 모델 옆에 실행 가능한 대안을 최대 세 개까지 보여주는 비교 보고서를 만든다. 각 대안에는 품질, 치명적 실패, 전체 경로 비용, p50/p95, 대체 경로 비율, 커버리지가 포함된다. 사용자가 선택한다. 주 경로가 실제로 실행된다는 증거가 없으면 활성화할 수 없으며, 대체 경로를 통해서만 성공하는 후보는 호출할 수 없다.

컴파일러가 보는 정보는 프롬프트, 스키마, 학습 예시 하나, 그리고 스스로 만든 합성 데이터뿐이다. 두 데모에서 보류 문서와 추적, 모든 정답 레이블은 데모 쪽에 남아 검색에 쓰이지 않았다.

모델처럼 호출할 때는 다음 코드를 쓴다.

from openai import OpenAI
import json

client = OpenAI(base_url="https://api.seldon-ai.com/v1", api_key=SELDON_API_KEY)

resp = client.chat.completions.create(
 model=f"seldon/function/{FUNCTION_ID}@{REVISION_ID}",
 messages=[{"role": "user", "content": json.dumps({"text": trace_fragment})}],
)
signals = json.loads(resp.choices[0].message.content)

엔드포인트는 OpenAI 호환이어서 OpenAI SDK, LiteLLM, LangChain, Vercel AI SDK를 그대로 쓸 수 있다. 모든 호출은 실제 청구액이 담긴 실행 영수증을 기록한다.

두 데모에서 Seldon이 교체한 것은 프롬프트가 호출하던 LLM 단계 하나뿐이다. 데이터 불러오기, 분할, 출력 확인, 가리기, 임베딩, 클러스터링, 점수 산정은 사용자 컴퓨터의 독립 실행형 demo.py에 있는 일반 Python 코드다. 데모는 Seldon 패키지를 가져오지 않고 일반 HTTP로 Function을 호출한다.

다이어그램의 색은 다음을 뜻한다.

• 보라색: 컴파일된 Function 안에서 Seldon이 호스팅하는 부분
• 회색: 애플리케이션 코드인 데모 스크립트
• 초록색: 사용자 CPU에서 실행하는 로컬 모델
• 주황색: Function 바깥에서 기준 모델 Sol을 직접 호출하는 단계
• 점선: 연결돼 있지만 이번 새 입력에서는 실행되지 않은 기준 모델 대체 경로

모든 기준선은 같은 스크립트를 거친다. Function이 교체하는 한 단계만 바꾸므로 비교는 그 단계만 측정한다.

데모 1: 에이전트 추적 분석

참고한 설계와 실험 설정

PostHog는 LLM 추적 클러스터링 구축 과정을 상세히 공개했고 코드도 연결했다. 공개된 설명에 따르면 각 추적을 줄 번호가 붙은 텍스트로 만들고, 긴 추적은 컨텍스트에 맞게 균일하게 줄인다. 매시간 일부 추적을 뽑아 GPT-4.1 nano로 구조화 요약을 만들고, text-embedding-3-large로 임베딩한 뒤 UMAP과 HDBSCAN을 적용한다. GPT-5.2 에이전트가 각 클러스터에 이름을 붙인다.

PostHog 설명은 이 문제의 절충도 다룬다. 모든 추적을 요약하면 비용이 커지므로 매시간 일부를 작은 고속 모델로 처리하고 Batch API로 옮길 계획을 세운다. 긴 추적의 일부 줄을 버리면 컨텍스트 제한에 맞출 수 있지만 정확도나 품질을 희생한다. 일반 요약 스키마 하나로는 추적 유형마다 다른 요구를 담기 어렵고, 사용자 프롬프트와 구조화 출력을 허용하는 방안은 향후 개선 가능성으로 제시됐다. 자유 문장보다 줄 참조를 포함한 구조화 스키마가 임베딩에 더 적합하다는 설명도 있다.

Seldon의 실험은 이 공개 설계에서 고정 프롬프트와 고정 스키마로 매번 실행되는 요약 단계를 함수형 LLM 호출로 보고 살펴봤다. 도구를 사용하는 다단계 라벨링 에이전트는 컴파일 대상이 아니며, 임베딩·UMAP·HDBSCAN·오케스트레이션은 사용자 코드에 남는다. 그림은 PostHog 코드가 아니라 공개 설명을 바탕으로 한 예시라는 점도 Seldon은 강조했다.

실험은 PostHog 시스템을 재현한 것이 아니라 전체적인 형태를 참고해 다른 조건을 시험한 자체 설정이다.

추출 계약은 사용자의 의도, 순서가 있는 행동, 관찰된 결과(completed / failed / unclear), 실패 신호를 요구한다. 각 신호에는 추적에서 정확히 인용한 근거가 있어야 하며 스크립트가 모든 인용을 코드로 확인한다.

호출 전 스크립트는 모든 추적에서 보상, 작업 ID, 시뮬레이터 상태를 삭제한다. 작업을 해시로 분할해 같은 작업의 반복 시도가 학습과 시험 사이에 섞이지 않게 한다. 호출 뒤에는 어느 청크에서든 근거 인용이 정확하지 않으면 추적 전체를 거부한다. 작업 ID는 마지막 점수 산정에만 쓴다.

대체 경로가 작동하는 조건은 제한적이다. 단계 출력이 스키마나 근거 검증에 실패하거나, 요청 전송 전에 서빙 허용 절차가 요청을 거부하면 같은 55초 기한 안에서 원래 Sol 호출을 실행한다. 제공자 호출의 결과가 불확실하면 대체 경로를 실행하지 않는다. 이미 처리됐을 가능성이 있는 요청을 두 번 보내지 않기 위해서다.

컴파일 결과와 클러스터링

검색 결과는 실행 가능한 대안 두 개였다. 첫 번째는 Luna 단독 사용과 Sol 대체 경로다. Sol의 보류 점수 74/80에 비해 Luna는 76/80을 기록했고 양쪽 모두 치명적 실패는 없었다. 요청당 비용은 20%였고 p50과 p95 모두 약 21% 빨랐다. 두 번째는 Jev 분류기가 outcome이라는 열거형 하나를 정하고, Luna가 그 결정을 문맥으로 받아 자유 텍스트 필드를 채우는 방식이다. 결정론적 코드가 각 필드를 한 번씩 설정해 최종 객체를 조립한다. 이 대안은 Sol과 통과율이 같았지만 치명적 실패가 두 건이었다.

Seldon은 결과를 받기 전에 선택 규칙을 기록했다. 먼저 품질이 가장 높은 대안을 고르고, 그다음 비용이 낮은 것, 마지막으로 p95가 낮은 것을 선택한다. 이에 따라 Luna를 선택해 활성화했다. 회사는 좁은 추출 작업에서 정확한 인용을 요구하면 큰 모델이 문장을 바꿔 말할 여지가 더 많아질 수 있다고 설명한다. 이 사례에서 개선은 더 저렴한 모델을 찾은 결과이며, Seldon의 역할은 기준 모델과 사용자 계약에 따라 이를 찾고 증명한 뒤 안전장치와 함께 제공하는 것이었다고 한다.

시드가 고정된 보류 추적 40개를 네 가지 표현 방식으로 처리했다. 각 비교군은 표현 단계만 바꾸고 청킹, 임베딩, UMAP, HDBSCAN 설정과 점수 산정은 같게 유지했다. 가운데 두 열은 같은 구조화 신호 계약을 Sol 직접 호출과 컴파일 Function으로 각각 실행한 결과다.

Seldon 파이프라인은 기준선보다 클러스터링 점수가 높았고(0.56 대 0.33), 호출당 비용은 22%였으며 지연 시간도 낮았다. 비용이 들지 않는 직접 작성 특징보다도 점수가 높았다. 자유 문장 요약은 작업 ID와 비교했을 때 무작위에 가까운 수준을 조금 웃돌았다. Seldon은 이 결과가 구조화 요약을 쓰는 PostHog의 설명을 뒷받침한다고 해석했지만, 자사의 요약 비교군은 PostHog 스키마가 아니라 Sol의 단일 자유 문장 필드였다고 덧붙였다.

다만 추출 방식 두 가지 모두 40개 가운데 20개만 완료했고, 실패 15개는 같은 추적이었다. 청크 하나라도 인용이 정확하지 않으면 전체 추적을 거부하는 데모의 엄격한 검사 때문에 긴 추적에서 실패가 잦았다. 긴 추적은 중앙값 기준 청크 6개였고 짧은 추적은 3개였다. Seldon은 이를 Sol보다 성능이 떨어진 결과가 아니라 시험 장치의 엄격한 기준으로 설명했다. 다음 버전에서는 청크별 점수를 매길 계획이다. ARI는 양쪽이 모두 완료한 15개 추적에서 작업 ID를 실제 클러스터 레이블의 대리값으로 사용했다. 따라서 실제 클러스터 품질의 증거라기보다 Seldon 신호가 적어도 Sol 신호만큼 군집화된다는 의미로 읽어야 한다.

추적 분석을 만드는 팀은 표본 추출, 긴 입력 축약, 맞춤 스키마, 근거 유지라는 절충을 고려해야 한다. Seldon은 품질 기준을 신뢰하는 모델로 정하고 그 기준을 지키는 가장 저렴한 프로그램을 찾은 다음 표본 추출을 얼마나 유지할지 결정할 수 있다고 제안한다. 다만 실험은 Sol을 기준으로 컴파일했으며 GPT-4.1 nano와 비교하지 않았다. nano급 모델은 Luna 프로그램보다 호출당 비용이 낮을 수도 있다. 비교 보고서의 장점은 특정 선택이 해당 스키마에서 품질을 얼마나 바꾸는지 수치로 보여주는 데 있다고 회사는 설명한다.

이 실험은 줄을 줄이는 대신 청크를 만들어 모든 문자를 처리했다. 긴 추적일수록 호출 수가 늘기 때문에 전체 범위를 처리하려면 호출 비용이 낮아야 한다. 균일 축약과 전체 처리를 직접 비교하려면 --summary-max-chars 24000으로 요약 비교군을 실행할 수 있다고 안내한다. 맞춤 스키마가 수천 개라면 각 스키마를 별도 Function으로 컴파일하고 기준 모델에 맞춰 측정해 모델 ID로 교체할 수 있지만, 이 사례의 컴파일에는 계약당 약 15달러와 두 시간이 들었다. 시연 조건에서는 약 1,000~2,300회 호출해야 비용을 회수하므로 일회성 필터에는 적합하지 않을 수 있다. 줄 참조 대신 코드에서 원문과 인용을 대조하는 방식은 프롬프트 지시만으로 막지 못한 실패를 찾아 다음 컴파일의 평가 대상으로 삼는다.

데모 2: 개인정보 식별

참고한 문제와 실험 설정

기업 데이터를 AI 연구소에 라이선스하는 회사는 먼저 데이터를 익명화해야 한다. Mercor는 공개 사례다. 데이터 페이지는 계약서, 사건 파일, 임상 기록, 보험금 청구, 보험 심사 자료, 고객 발표 자료, 청구서, 배송 명세서 등 기업의 일상 업무 데이터를 라이선스한다고 설명한다. 홈페이지는 자동 익명화가 민감 식별자 60개가 넘는 범주를 가린다고 밝힌다.

Seldon은 Mercor의 익명화가 어떻게 구성됐는지 모르며 회사를 대표하지 않는다고 선을 그었다. 실험은 Mercor 시스템을 설명하거나 시험하거나 경쟁하지 않는다. 공개된 설명에서 대규모 익명화 파이프라인이 마주하는 문제의 형태만 참고했다. 누락 없이 찾는 것이 중요하고, 과도하게 가리는 데도 비용이 든다. 대량 처리에서는 문서당 프런티어 모델 호출 비용과 지연이 누적된다. 실제 파일에는 지시처럼 보이는 이메일과 메모가 있어 LLM 탐지기가 거부하거나 그 내용을 따를 수도 있다. 또 모델이 올바른 엔티티를 찾아도 문자 위치가 틀리면 정보가 새고, 60개가 넘는 범주와 여러 문서 유형은 각각 다른 탐지 계약을 요구한다.

실험은 make_corpus.py --seed 20261012로 만든 채용 문서 형태의 가상 말뭉치 66개와 정답 엔티티 264개를 사용했다. 선별 메모, 이력서, 면접 발췌문, 추천인 요청, 계약자 청구서, 개인정보가 없는 문서, 지시문이 삽입된 표지 메모를 포함했다. 레이블은 PERSON, ORGANIZATION, EMAIL, PHONE, INVOICE 다섯 개로, 60개 범주 문제의 일부만 다뤘다. 엔티티를 일부만 가려도 누출로 계산했다. Mercor나 다른 회사의 데이터는 사용하지 않았다.

Function은 정확한 유니코드 위치의 범위만 식별한다. 범위의 비식별 처리와 가명화는 결정론적이며 사용자 코드에서 실행한다.

파이프라인 결과

활성화된 프로그램의 주 경로에는 LLM이 없다. 세 단계 중 모델을 호출하는 것은 첫 단계뿐이다. GLiNER가 원문과 대조해 검증된 위치의 범위를 반환하고, 결정론적 커널 두 개가 새 정보를 추론하지 않고 해당 범위를 출력 스키마에 맞게 변환한다. 단계 검증에 실패하면 원래 Sol 호출을 실행하지만 새 문서에서는 대체 경로가 필요하지 않았다.

네 가지 비교군 모두 같은 검증·가리기·점수 산정 코드를 거쳤다. 범위가 부분적으로만 덮인 엔티티는 어느 방식에서 나왔든 누출로 계산했다. Sol이 모든 문서를 처리하지 못했기 때문에 네 비교군이 모두 완료한 53개 문서만으로도 공정한 비교를 따로 제시했다.

Seldon 파이프라인은 66개 문서를 모두 처리하는 데 총 $0.00014가 들었다. Sol은 약 $1.14를 썼다. 게이트웨이 경유 기준 Seldon은 p50에서 약 4배, p95에서 약 6배 빨랐고, Seldon의 순차 실행 시간 기준으로는 10배 빨랐다. 로컬에서 네트워크 연결 없이 실행하는 Presidio는 더 빨랐다.

기준선은 작업을 끝내지 못했다. 삽입된 지시문이 있는 표지 메모 8개 모두 HTTP 400 invalid_request로 돌아왔다. 게이트웨이와 제공자 가운데 어느 쪽이 거부했는지는 아직 진단하지 못했다. 다른 출력 5개는 위치가 가리키는 텍스트와 맞지 않았다. Seldon은 그 8개를 포함해 66개 모두 처리했다. 범위 모델은 지시문을 따르지 않고 토큰에 레이블을 붙이므로 삽입된 지시를 지시로 받아들이지 않는다는 것이 Seldon의 설명이다. 익명화 과정에서 거부된 문서는 누락이 되며, 제외되거나 가리지 않은 채 나갈 수 있다.

하지만 가장 정확한 비교군은 아니며 Seldon도 이를 인정했다. Seldon은 14개 문서에서 누출을 냈고, Sol은 완료한 53개 문서에서 누출이 없었다. Seldon의 누락은 모두 면접 발화자 표기인 “Wen: …”이나 이메일 인사말 “Hi Kalani,”처럼 단독으로 나온 이름이었다. PERSON 엔티티 94개 중 20개를 놓쳤다. 전체 이름, 조직, 이메일, 전화번호, 청구서 ID는 모두 찾았다. 개인정보가 없는 문서에서는 “a 1–4 scale”의 “1–4”를 INVOICE로 잘못 표시하는 과잉 가리기도 반복됐다.

로컬 Presidio + GLiNER는 96.2%를 처리해 Seldon보다 높은 재현율을 보였다. 대부분의 누락은 데모 자체의 청구서 정규식에서 생겼으며, 한 줄 수정으로 99%에 가까워질 가능성이 있다고 Seldon은 설명했다. 이는 실제로 넘어야 할 기준이라고 덧붙였다.

Seldon의 컴파일 시점 보고서는 기준 모델 83.8%에 비해 파이프라인을 80.0%로 평가했고, 이 작업의 자체 품질 측정이 신뢰하기 어렵다고 표시했다. 사전에 등록한 선택 규칙에 따라 종단 간 측정을 위해 파이프라인을 활성화한 것은 의도적인 결정이었다. 비교 보고서가 선택을 대신하지 않고 필요한 수치를 숨기지도 않는다는 점을 보여주려는 것이라고 Seldon은 설명한다.

이 도구는 가상 데이터의 가명화 도구이며 익명화 인증이 아니다.

Seldon은 검증된 위치를 반환하는 범위 모델이 모든 문서를 비용 거의 없이 처리하고 게이트웨이 경유로 문서당 약 2초 이내에 끝났다고 설명한다. 이는 모든 문서를 처리해야 하는 경우 재실행·재검사·감사의 비용에 영향을 줄 수 있다. Sol은 합성 과제에서 문자 위치를 일관되게 맞추지 못하는 경우가 있었고, 특화 범위 모델은 Function에서 결과가 나가기 전에 원문과 대조해 검증한다.

계약서, 임상 기록, 청구서의 민감정보 60개 범주는 하나의 탐지 문제로 볼 수 없다는 것이 회사의 설명이다. 문서 유형이나 범주 묶음별로 Function을 만들고 각자 기준 모델과 비교할 수 있다. 활성화 전에 대안별 누출률을 확인할 수 있다.

Seldon은 우선 단독 이름 누락을 고쳐야 한다고 밝혔다. 이는 개인정보 보호팀이 먼저 확인할 누출 유형이므로 재현율을 확보하기 전에는 성과를 주장할 수 없다는 설명이다. 오류 분석에서 나온 개선안은 프롬프트의 레이블 설명을 단순 열거형 이름 대신 사용하기, 추출 임계값을 검색 변수로 만들기, “Wen Iyer”를 발견하면 이후 “Wen”도 가리는 결정론적 이름 전파 커널을 추가하기다. 이는 제안일 뿐 출시된 기능은 아니다. 그 뒤에는 범위 모델이 대부분을 처리하고 신뢰도가 낮은 문서만 프런티어 모델에 보내는 혼합 방식이 개인정보 보호팀이 원할 만한 다음 단계라고 제안했다.

실패와 한계

공개된 결과에 앞서 호출 가능한 리비전을 만들지 못한 프로덕션 실행이 여러 차례 있었다. Seldon은 이러한 실패가 제품 설계에 성공 사례만큼 영향을 줬다고 밝혔다.

첫째, 프런티어 모델이 자기 결과를 일관되게 재현하지 못했다. Seldon은 검색 전에 기준 모델의 안정성을 확인한다. 개인정보 과제에서 Sol에 같은 질문을 두 번 했을 때 실행별로 20회 가운데 13~16회만 결과가 일치했다. 불일치는 모두 엔티티 텍스트와 레이블은 같고 문자 위치만 달랐다. 별도로 답변 156개 중 11개는 위치가 지정한 텍스트와 맞지 않았다. Seldon은 LLM에 문자 수를 세게 하는 것이 약한 계약이라고 보고 두 가지 방법을 추가했다. align_spans는 LLM이 인용한 텍스트를 원문에서 찾아 위치를 계산하며, 텍스트가 없거나 여러 위치에 있어 모호하면 거부하는 결정론적 커널이다. GLiNER 같은 기본 범위 모델은 검증된 위치를 직접 반환한다. 최종 선택 파이프라인은 두 번째 방식을 쓴다.

둘째, 통과·실패 기준 하나만 두면 유용한 결과가 사라졌다. 초기 실행은 후보가 품질 95% 이상, 기준 비용의 70% 이하, 기준 p95의 110% 이하를 모두 충족하지 않으면 아무것도 출시하지 않았다. 한 추적 실행에서 Luna는 답변된 사례 기준 97.45%로 Sol의 96.82%보다 높았고 비용은 약 5분의 1이었지만 호출 가능한 리비전은 나오지 않았다. 기준 모델이 거부한 입력이 분모에서 빠지면서 자격 판정도 막혔다. 이에 따라 Seldon은 단일 통과 기준을 비교 보고서로 바꿨다. 목표치는 검색을 유도하고 측정값은 공개하며 최종 선택은 사용자가 한다.

셋째, 초기 비용 예상이 한도를 넘었다. 첫 미리보기는 $57.83과 $72.24를 예상했지만 당시 상한은 $25였다. 최적화는 실행을 거부했고, 자격을 얻지 못한 활성화 요청은 409를 반환했다. 가짜 리비전으로 대체하지 않았으며 예상치와 운영 한도를 먼저 조정해야 했다.

넷째, 부하 상태에서 서빙이 두 차례 실패했다. 비교 실행 중 Seldon 호출 두 건이 HTTP 502로 빠르게 실패했다. 추적 리비전은 호출당 약 13만 5,000토큰을 예약했고, 같은 작업 공간에서 실행 중이던 개인정보 컴파일이 해당 공간의 분당 토큰 한도를 소진했다. 이에 따라 제공자 호출 전에 서빙 허용 절차가 실패했다. 두 영수증 모두 비용은 $0이었다. Seldon은 원인을 찾아 PR #584에서 수정했다고 밝혔다.

비용 회수와 공개 범위

컴파일은 일회성 비용이다. Seldon이 제시한 대략적인 손익분기 계산은 다음과 같다.

• 추적 신호: 컴파일 $14.58, 추적 길이에 따라 호출당 $0.0064~$0.0147 절감. 약 1,000~2,300회 호출에서 비용을 회수한다.
• 개인정보 식별: 컴파일 $17.12, Sol 대비 문서당 약 $0.018 절감. 약 950개 문서 뒤에 비용을 회수한다.

다만 두 컴파일에는 아직 정산되지 않은 보류 금액이 있었다. 추적은 $3.87, 개인정보 식별은 $8.48이다. 전액 정산되면 손익분기점은 약 2,900회 호출과 1,400개 문서로 늘어난다. 이 계산에는 사용자 측 엔지니어링 시간과 로컬 기준선의 자체 호스팅 비용이 포함되지 않는다. 허용하는 누락의 비용도 포함되지 않으며, 그 금액은 사용자만 정할 수 있다고 Seldon은 밝혔다.

전체 비교 실행의 지갑 청구액은 승인된 100달러 가운데 $40.35였다. 임시 API 키는 이후 폐기됐고 401을 반환하는지 확인했다고 한다.

Seldon은 PostHog의 공개 글과 Mercor 같은 회사가 공개한 익명화 수요에서 영감을 얻었을 뿐 두 회사를 대표하거나 그들과 경쟁하지 않는다고 밝혔다. 두 회사는 관여하거나 승인하지 않았으며 두 회사의 코드나 데이터도 사용하지 않았다. 추적 실험은 PostHog 설계의 전체적인 형태를 참고했지만 임베딩이 다르고 표본 추출과 라벨링 에이전트가 없다. 요약 비교군도 GPT-4.1 nano의 구조화 스키마가 아니라 Sol의 자유 문장 요약이며 nano와 비교하지 않았다.

Mercor의 내부 방식은 알지 못한다. 개인정보 데모는 템플릿으로 만든 가상 문서에서 다섯 범주만 다뤘으며 실제 문서보다 단순하다. 이 문서에서의 92.4% 처리율은 실제 데이터의 개인정보 보호를 보장하지 않는다. 보류 보고서는 Seldon이 만든 합성 예시를 사용했고 외부 비교는 공개 벤치마크와 가상 문서를 사용했으므로 어느 쪽도 실제 프로덕션 트래픽이 아니다.

추적 ARI는 짝지은 15개 추적에서 작업 ID를 대리값으로 삼은 지표다. 클러스터의 응집도는 사람이 검토해야 한다. 지연 시간은 한 클라이언트 위치에서 순차적으로 요청을 보낸 측정값이며 프로덕션 SLO를 나타내지 않는다.

벤치마크에 사용한 코드베이스는 곧 오픈소스로 공개할 예정이라고 Seldon은 밝혔다. Seldon은 공개 베타에서 반복되는 작업 가운데 특화 프로그램의 이점을 얻을 만한 작업을 찾아 트래픽을 라우팅해 볼 수 있다고 안내한다.