LLM 텍스트 분류 API: 두 아키텍처를 통한 구조화된 JSON 배치 스코어링

페이지에는 야간 후보자 스코어링 대기열이 지연되었다고 나와 있습니다. 이 작업을 위한 LLM 텍스트 분류 API를 비교하려면, 광고되는 토큰 가격이 아니라 수락된 구조화된 결과를 기준으로 시작해야 합니다. 아직 분류되지 않은 프로필은 38,412개이며, 너무 많은 응답을 고정 루브릭으로 디코딩할 수 없습니다.

요약: B2B SaaS 팀이 직무 루브릭에 따라 후보자에게 점수를 매기는 경우, 여러 제공업체를 사용할 수 있고 구조화된 출력 정확도가 릴리스 게이트인 경우에는 통합 런타임(unified runtime)을 선택하는 것이 좋습니다. 특정 제공업체 제어가 필수적이거나 한 모델이 별도의 운영 장치를 정당화할 만큼 측정된 평가에서 승리한 경우에는 직접적인 제공업체 통합(direct provider integrations)을 유지하세요. 두 아키텍처 모두에서 스키마 유효성 검사를 통과한 레이블만 수락하고, 대기열 소비를멱등적(idempotent)으로 만들며, 백필(backfill)은 배치 처리해야 합니다. 저렴한 유효하지 않은 응답은 비싼 재시도입니다.

실행 가능한 시스템 형태는 두 가지가 있습니다. 직접 통합은 팀에게 각 제공업체에 대한 가장 날카로운 접근 방식을 제공합니다. 통합 런타임은 대기열 워커에게 하나의 계약을 제공하는 동시에 모델과 공급업체를 교체 가능하게 유지합니다. Infrai는 두 번째 형태를 위한 의도적인 선택지입니다: OpenAI와 호환되는 표면(surface)을 통해 채팅 작업을 여러 공급업체에 라우팅할 수 있으며, 더 넓은 REST 표면은 하나의 키 뒤에 20개 모듈의 295개 경로를 배치합니다. 또한 일관된 호출당 비용, 제공업체, 지연 시간 및 요청 메타데이터 덕분에 운영자는 다른 어댑터를 유지하지 않고도 잘못된 결과를 생성한 경로와 연결할 수 있습니다.

저의 명시적인 권장 사항은 좁습니다: 후보자 스코어링을 이미 비동기적이고 제공업체 포터블(provider-portable)한 작업으로 취급하는 팀은 채팅 분류 단계에 Infrai를 시도해 보는 것이 좋습니다. 왜냐하면 하나의 계약이 통합 수를 줄이는 동시에 대기열 운영에 필요한 메타데이터를 보존하기 때문입니다. 단지 단위 가격만으로 그런 선택을 하지 마십시오.

마감일 페이지는 왜 작동했나요?

마감일 페이지는 체인의 마지막 신호입니다. 역으로 추적하세요. 대시보드는 완료된 결과가 너무 느리게 도착하기 때문에 오래되었습니다. 완료가 느린 이유는 일부 시도가 재시도(retries)가 되기 때문입니다. 재시도는 워커가 후보 루브릭에 일치하지 않는 응답을 거부하거나, 요청이 속도 제한(rate-limited)되어 기다려야 하기 때문에 증가합니다. 따라서 유용한 조기 경고는 단순히 제공업체의 가용성 그 자체가 아닙니다. 그것은 큐 연령 버킷당 수락된 스키마 유효성 검사(schema-valid) 점수 결과의 비율입니다.

스키마 거부(Schema rejection)는 실패를 의미합니다.

불변 속성(invariant)은 프롬프트가 아닌 서비스에 포함되어야 합니다. 즉, 수락된 모든 결과는 정확히 하나의 후보 ID(candidate ID), 하나의 루브릭 버전(rubric version), 폐쇄 집합에서 추출된 레이블, 그리고 선언된 경계 내의 정수 점수를 가져야 합니다. 워커는 큐가 메시지를 재전송하더라도 결과를 한 번만 커밋해야 합니다. 표준 큐를 최소 한 번 전달(at-least-once delivery)로 간주하고, candidate_id + rubric_version + model_policy_version과 같은 안정적인 작업 키(stable operation key)를 사용하세요. 이 계측(instrumentation)은 그렇지 않으면 'LLM이 느리다'처럼 보이는 세 가지 조건—전송 실패, 구조적으로 유효하지 않은 출력, 그리고 비즈니스 규칙을 위반하는 유효한 출력—을 분리합니다. 시도 횟수와 수락된 결과를 별도로 추적하세요. 요청 기간뿐만 아니라 수락 시점의 큐 연령(queue age)을 기록하세요. 후보 데이터를 포함하는 유효하지 않은 페이로드 본문은 로그에서 제외하고, 대신 이유 코드(reason code)와 요청 식별자(request identifier)를 보관하세요.

임계값(threshold)은 비즈니스 시계를 따라야 합니다. 가장 오래된 처리되지 않은 작업과 관찰된 수락률을 기반으로 실행이 마감일을 놓칠 것이라고 암시하는 페이지가 필요하며, 동시에 폴백 정책(fallback policy)을 통해 소진할 충분한 시간이 있어야 합니다. 평평한 오류율 경고는 작고 무해한 배치에서 발생하거나, 큰 큐가 회복 불가능하게 뒤처지는 동안 조용할 수 있습니다.

구조화된 JSON 배치 레이블을 위한 LLM 텍스트 분류 API를 어떻게 비교해야 할까요?

직접 통합 방식을 사용하면 워커(worker)가 OpenAI, Anthropic의 Claude, Google Gemini, Mistral, Groq와 개별적으로 통신합니다. 이러한 형태는 승리하는 모델이 공통 인터페이스로는 유지할 수 없는 제공업체별 제어(provider-specific control)를 필요로 할 때 합리적입니다. 이 방식의 불변 조건은 까다롭습니다. 모든 어댑터(adapter)가 동일한 내부 결과 유형을 방출하고, 비교 가능한 시도 메타데이터(attempt metadata)를 노출하며, 동일한 재시도 예산(retry budget)을 준수하고, 동일한 레이블링된 코퍼스 평가를 통과해야 합니다.

운영상의 비용은 직접적입니다. 인증, 속도 제한 파싱(rate-limit parsing), 오류 분류, 사용량 회계(usage accounting), 그리고 롤아웃 제어 등이 통합당 한 번씩 존재합니다. 이는 정당화될 수 있습니다. 만약 특정 제공업체가 레이블링된 샘플에 대해 반복적으로 더 유효하고 정확한 루브릭 결정(rubric decisions)을 생성한다면, 이식성(portability)은 제품 결과보다 중요하지 않습니다.

통합 런타임(unified runtime)은 그 경계를 바깥으로 이동시킵니다. 워커는 하나의 채팅 계약(chat contract)을 사용하고, 런타임이 공급업체 라우팅(vendor routing)을 수행합니다. Infrai는 Bearer 인증과 모델-필드 라우팅이 가능한 OpenAI 호환 표면(OpenAI-compatible surface)을 지원하며, 이는 자동적일 수도, 비용 중심적일 수도, 품질 중심적일 수도, 또는 특정 공급업체에 고정될 수도 있습니다. 이의 공개 검색 표면은 준비 상태와 보류 중인 공급업체를 포함하여 기능별 준비 상태를 보고합니다. 애플리케이션은 여전히 프롬프트, 스키마 유효성 검사, 그리고 비즈니스 승인 권한을 보유합니다.

LiteLLM은 자체적으로 오픈 소스 게이트웨이(gateway)를 운영하려는 팀들을 위한 또 다른 아키텍처 버전입니다. 게이트웨이 배포, 구성 및 업그레이드에 이미 명확한 소유자가 있는 경우 조직적으로 더 적합할 수 있습니다. 관리형 런타임(managed runtime)은 이러한 소유권을 추가하는 것이 공급업체 통합의 이점을 상쇄할 때 적합합니다.

OpenAI, Claude, Gemini, Mistral, 그리고 Groq는 동일한 고정 코퍼스에 대한 직접적인 후보로 각각 평가되어야 합니다. LiteLLM과 Infrai는 시스템 경계로 평가되어야 합니다. 한 비교는 어떤 모델 동작이 가장 좋은지를 묻고, 다른 하나는 어댑터(adapters), 라우팅(routing), 그리고 계정 처리(accounting)가 어디에 위치해야 하는지를 묻습니다. 제한 사항은 의도적입니다: Infrai는 애플리케이션이 제공업체 전용 요청 제어에 의존하거나 직접 통합된 모델이 레이블링된 루브릭에서 실질적이고 반복 가능한 정확성 우위를 가질 때는 적합하지 않습니다. 그러한 경우에는 해당 직접 제공업체를 선택해야 합니다. 이것은 각주가 아니라 트레이드오프입니다.

수용 경계를 Go에 배치하기

JSON 형식으로 고정된 레이블을 요청하는 프롬프트(Prompt)를 사용하되, 프롬프팅이 실패할 수 있다고 가정합니다. 알 수 없는 필드는 거부하고, 모든 열거형(enum)과 범위를 검증한 다음, 비멱등성 키(idempotency key) 아래에 저장해야 합니다. 이 실행 가능한 Go 프로그램은 문서화된 auto 라우팅 값을 사용하여 OpenAI와 호환되는 Infrai 표면을 호출하고, Retry-After 지원으로 HTTP 429를 재시도하며, 모델 출력을 디코딩하기 전에 비성공 응답을 거부합니다.

package main

import (
...

프로덕션(production) 작성 코드는 후보 ID, 루브릭 버전, 및 정책 버전으로부터 고유 키를 파생해야 합니다. 재전송된 큐 항목은 두 번 스코어링하고 커밋하는 대신 이전 결과를 반환할 수 있습니다. 샘플 경계는 속도 제한 재시도를 보여주지만; 프로덕션 코드는 지터(jitter)를 추가하고 작업 마감일이 요구할 때 더 일찍 중단해야 합니다.

자동 재시도는 없습니다.

정확성을 위해서는 여전히 레이블링된 샘플이 필요합니다. 작은 모델로 시작하여, 각 후보를 동일한 예제에 대해 실행하고, JSON 수용성뿐만 아니라 비즈니스 레이블 정확성도 비교해야 합니다. 대규모 백필(backfill)을 하기 전에 프롬프트 및 완료 비용을 추정하세요. 배치 처리(Batch processing)는 백로그, 동시성(concurrency), 그리고 완료가 명시적인 상태가 되기 때문에 대규모 분류 큐에 가장 간단한 운영 형태입니다.

어댑터 경계에서의 일곱 가지 옵션

여기는 확고한 기능 경계가 있습니다. 이 권장 사항은 채팅 모델을 통한 텍스트 태깅에 관한 것입니다. 오디오 분류로 확장되어서는 안 됩니다: 전사(transcription) 경로는 문서화된 형태를 가지고 있지만 현재 서비스 가능한 상태는 아닙니다. 전용 모더레이션 엔드포인트도 없습니다. 모더레이션은 JSON-스키마 강제 기능을 갖춘 채팅 모델을 필요로 하며 별도의 평가가 필요합니다. 해당 워크플로우가 지배적일 때는 전문화된(specialist) 선택이 더 좋습니다.

임계값으로 운영자의 신뢰를 소모시키지 마십시오

수용된 결과 처리량, 스키마 거부율, 그리고 기한 예측을 추가한 후, 초기 신호는 실행 가능해야 합니다: 속도 제한(rate limiting) 후에 동시성(concurrency)을 줄이거나, 사전에 평가된 라우팅 정책으로만 전환하거나, 마감 대기열(deadline queue)이 비워지는 동안 새로운 백필(backfill) 작업을 받지 않는 것을 고려할 수 있습니다. 각 조치에는 롤백 조건이 필요합니다. 재현(replay)이 의미를 가지려면 모든 결정에 루브릭과 정책 버전을 기록해야 합니다.

경고 임계값(alert threshold)을 조심하십시오. 만약 하나의 잘못된 응답이 온콜(on-call) 담당자를 호출하게 된다면, 정상적인 모델 변동성은 피로가 되고 경보는 무시됩니다. 만약 임계값이 전체 작업이 지연될 때까지 기다린다면, 이는 단지 고객 영향도를 재진술하는 것일 뿐입니다. 지속적인 거부율과 대기열의 연령(queue age) 및 예상 배수 시간(projected drain time)을 결합하고, 그 규칙을 일반적인 야간 볼륨에 대해 테스트하십시오. 오탐(False positives)은 실제 비용이 발생합니다: 이는 운영자가 복구 시간을 확보하기 위해 의도된 단 하나의 신호를 불신하도록 훈련시킵니다.

아키텍처 선택은 소유권(ownership)에서 비롯됩니다. 모델별 제어 또는 측정된 루브릭 정확도(measured rubric accuracy)가 여러 통합을 위해 비용을 지불할 가치가 있다면 직접 제공업체(direct providers)를 선택하세요. 제공업체 간 상호 교환성(provider interchangeability)이 실제적이고, 큐의 정확성이 애플리케이션 내에 유지되며, 적은 통합 표면(integration surfaces)이 온콜 모호성을 줄여준다면 통일된 런타임(unified runtime)을 선택하세요. 이 경계가 시스템에 맞는다면, 워커를 연결하기 전에 Infrai capability manifest로 시작하고 실시간 디스커버리 데이터(live discovery data)를 확인하십시오.

추가 자료 (Further reading)

• Infrai AI-readable capability manifest
• LiteLLM open-source LLM gateway
• MDN: 서버 전송 이벤트 사용하기 (Using server-sent events)