레이블링 엔진 설정
labeling_engine 블록의 모든 키를 다룹니다. 소스와 신뢰도 방식, 사람 풀, 크라우드 비용, 예산, 런타임 제한, 기능, 그리고 검증이 거부하는 항목을 설명합니다.
레이블링 엔진이 하는 모든 일은 labeling_engine 블록 하나에서 설정합니다. 블록이 유효하지 않으면 서버가 시작 단계에서 멈추고 모든 문제를 한꺼번에 나열합니다. 주석자에게 엔진의 요청을 제공하려면 assignment_strategy: engine도 설정하세요. 엔진을 켜지 않은 채 이 전략을 설정하면 검증 오류가 납니다.
블록은 다음 섹션으로 이루어지며, 각 섹션은 아래에서 다룹니다.
assignment_strategy: engine
labeling_engine:
enabled: true
schemas: [sentiment] # default: every scheme a source can label
sources: []
cascade: [laya, gemma] # default: the first source alone
contracts: []
humans: {}
crowd: {}
budgets: {}
runtime: {}
features: {}
redaction: {}
distill: {}최상위 키
labeling_engine 바로 아래에는 키 다섯 개가 있습니다.
| 키 | 기본값 | 의미 |
|---|---|---|
enabled | false | 엔진을 켭니다. 켜진 엔진에는 소스가 하나 이상 필요합니다. |
schemas | 전체 | 엔진이 레이블을 다는 주석 스키마입니다. assignment_strategy: engine에서 빠진 스키마는 모든 항목이 아니라, 엔진이 자기 스키마를 위해 사람에게 보내는 항목에서만 답을 받으며, 검증이 이에 대해 경고합니다. 어떤 소스도 레이블을 달 수 없는 스키마(예: 자유 텍스트)는 엔진에 포함할 수 없으므로, 이 전략에서는 모든 항목에서 답을 받는 일이 없습니다. 모든 항목에서 답을 받아야 한다면 다른 할당 전략을 쓰세요. |
sources | [] | 모델입니다. 소스를 참고하세요. |
cascade | 첫 번째 소스 | 시도하는 순서대로 나열한 소스 id입니다. 마지막 소스 다음에는 사람이 맡습니다. |
contracts | [] | 레이블이 충족해야 할 조건입니다. 계약을 참고하세요. |
소스
소스는 각 항목에 대해 레이블과 신뢰도를 제안하는 모델 또는 기존 레이블 집합입니다. 모든 소스에는 고유한 id와 kind가 있으며, 소스에 알 수 없는 키가 있으면 오류입니다.
| 키 | 기본값 | 의미 |
|---|---|---|
id | 필수 | cascade, 호출 로그, 인증서에서 쓰는 이름입니다. |
kind | 필수 | llm, vlm, decision, detector, judge, jury, trained, static, fixture, asr, lf, simulator 중 하나입니다. |
endpoint_type | llm, vlm, decision, judge에서 필수 | vllm, openai, anthropic, gemini, ollama, openrouter, openai_vision, ollama_vision, laya, systemone 같은 AI 엔드포인트입니다. detector의 기본값은 yolo입니다. |
model | 엔드포인트 기본값 | 모델 이름입니다. |
base_url | 없음 | 자체 호스팅 또는 OpenAI 호환 엔드포인트의 서버 URL입니다. |
api_key | 없음 | 버전 해시에 절대 들어가지 않으며 내보내지지도 않습니다. ${ENV_VAR}는 치환됩니다. |
temperature | 0.0 | 0에서 2 사이입니다. |
max_tokens | 256 | 호출당 출력 토큰 제한입니다. |
timeout | 엔드포인트 기본값 | 호출당 초 단위 시간입니다. |
prompt | 스키마로부터 생성 | 프롬프트 템플릿입니다. 바꾸면 새 소스 버전이 됩니다. |
confidence | {method: auto} | 소스가 신뢰도를 산출하는 방식입니다. 신뢰도 방식을 참고하세요. |
concurrency | runtime.concurrency | 이 소스에 대한 병렬 호출 수입니다. |
schemas | 엔진의 모든 스키마 | 소스를 이 스키마로 제한합니다. |
options | {} | 종류별 옵션으로, 아래에 나열되어 있습니다. |
judge | {} | judge 전용입니다. options와 같은 옵션을 별도 키 아래에 두며, 둘 다 같은 옵션을 설정하면 options가 우선합니다. |
members | 없음 | jury 전용입니다. 다른 소스 id 두 개 이상입니다. |
aggregation | plurality | jury 전용입니다. 규칙은 다수결(plurality) 하나뿐입니다. |
field / predictions_file | 없음 | static 전용입니다. 기존 레이블이 있는 위치입니다. 필드에는 {scheme: label}이 들어가며, 소스가 스키마 하나에만 레이블을 다는 경우에는 레이블만 들어갈 수도 있습니다. 모든 항목에서 필드의 형태가 맞지 않으면 그 필드를 짚는 메시지와 함께 실행이 실패합니다. |
error_rate, seed | 없음 | fixture 전용입니다. 테스트용으로 오류율이 알려진 합성 소스입니다. |
revision | 없음 | 버전에 기록할 모델 리비전입니다. 예를 들면 체크포인트 해시입니다. |
답을 바꿀 수 있는 모든 것(모델, 프롬프트, temperature, 옵션)은 소스의 버전 해시에 들어갑니다. 새 버전이 생기면 그 소스에 의존하는 모든 계약이 stale이 됩니다.
스키마가 가질 수 없는 값인 답, 예를 들어 목록에 없는 레이블, 숫자가 아닌 숫자 필드, N개 중 하나 선택 스키마에 대한 목록은 오류로 기록되며 레이블로는 절대 기록되지 않습니다. 실행 메시지는 이런 오류의 수를 셉니다. 호출이 실패한 항목은 이후 실행에서 소스 버전당 최대 세 번까지 다시 요청되며, 그 뒤에는 소스가 바뀔 때까지 기다립니다(키나 프롬프트를 고치면 새 버전이 됩니다). 한 소스가 실패한 실행에서도 다른 단계는 멈추지 않습니다. 다음 단계가 모든 항목에 레이블을 달고, potato label run은 상태 1로 종료하며 실패한 소스를 알려 줍니다.
신뢰도 방식
엔진의 수락 규칙은 각 예측의 신뢰도에 임계값을 적용하므로, 소스가 신뢰도를 어떻게 산출하는지가 엔진이 얼마나 수락할 수 있는지를 결정합니다. confidence.method는 다섯 가지 값 중 하나를 받습니다.
confidence.method | 적용 대상 | 동작 |
|---|---|---|
verbalized | llm, vlm, judge | 모델이 답에 0-100 사이의 값을 직접 밝힙니다. 호출은 한 번이며, 가장 신뢰도가 낮은 방식입니다. |
k_sample | llm | sample_temperature(기본 0.7)로 samples개(기본 5개)의 답을 받습니다. 가장 흔한 답이 레이블이 되고, 그 답의 비율이 신뢰도가 됩니다. 호출 k번의 비용이 듭니다. |
logprob | llm | 레이블에 글자를 붙이고 모델이 글자 하나로 답하며, 신뢰도는 첫 토큰의 확률에서 읽습니다. 호출은 한 번이며, 대개 보정이 가장 잘 되어 있습니다. logprob을 반환하는 백엔드(vLLM, OpenAI 호환)와 최대 20개의 레이블이 필요하며, 레이블이 더 많은 스키마는 검증 오류입니다. |
native | decision, detector, trained | 모델 자체의 확률입니다. llm 소스에서는 검증 오류입니다. |
auto | 전체 | 소스에 native가 있으면 그것을, 없으면 verbalized를 씁니다. |
종류별 옵션
다섯 가지 소스 종류는 각자의 옵션을 읽습니다.
- **
decision**은 프로세스 내 Laya, 또는 호스팅된 Jev나 OpenJev 같은 모든/v1/systemone서버를 다룹니다. 순전파 한 번으로 모든 선택지의 확률을 돌려주며,radio,select,likert,slider스키마에서 동작합니다.endpoint_type은laya또는systemone이어야 하고,systemone에는 서버 루트인base_url이 필요합니다(/v1/systemone으로 끝나는 URL도 받아들입니다). 두 경우 모두 상태는{"text": ...}로 전송되므로 하나의 체크포인트가 프로세스 안에서든laya-serve뒤에서든 같은 답을 내며,options: {state_key: ""}를 쓰면 대신 문자열만 그대로 보냅니다. 평가 척도(likert,slider)에서는 Laya의 점수가 척도를 거의 따라가지 못할 수 있으므로, 의존하기 전에 항목 몇 개를 확인하세요. 프로세스 내laya엔드포인트에는pip install 'potato-annotation[decision]'이 필요합니다. - **
detector**는image_annotation스키마에서 객체 탐지기의 상자를 읽습니다.keep_threshold(0.35)는 상자가 예측에 포함되는 최소 점수를 정합니다.candidate_threshold(0.05)와keep_threshold사이의 상자는 이미지의 신뢰도를 낮춥니다.label_map은 탐지기의 클래스를 스키마 레이블에 대응시키며, 대응되지 않은 클래스는 무시됩니다.image_field는 이미지 경로나 URL이 있는 항목 필드를 지정합니다. 경로는 주석 페이지와 같은 방식으로 해석되어,/media/x.jpg는 작업의media_directory아래에서, 상대 경로는task_dir아래에서 찾습니다. - **
judge**는rubric(기본값은 스키마의 설명),fields(판정자에게 보여 줄 항목 필드, 순서대로), 그리고 레이블 순서를 뒤집어 두 번 묻고 판정이 뒤바뀌면 기권으로 처리하는swap_order를 받습니다. 에이전트 트레이스 스키마(process_reward,trajectory_eval, ...)에서는 판정자가 각 단계에 레이블을 답니다. - **
vlm**은 비전 엔드포인트(openai_vision,anthropic_vision,ollama_vision)를 씁니다. OpenAI 호환 서버 뒤에 있는 자체 호스팅 모델에는openai_vision과base_url을 쓰세요. - **
trained**는artifact_dir,trainer(기본값sklearn-text),run_id를 받습니다. 이 소스는 대개 직접 작성한 설정이 아니라 증류 과정에서 만들어집니다.
humans
humans 블록은 누가 레이블을 달고 엔진이 어떻게 표본을 뽑는지 정합니다.
| 키 | 기본값 | 의미 |
|---|---|---|
pools | [team] | 레이블을 다는 사람: team, crowd, solo. |
calibration_rate | auto | 블라인드 보정을 위해 표본으로 뽑는 항목의 비율입니다. auto는 계약의 추정에서 비율을 고르는데, 클래스마다 검정이 가능할 만큼의 레이블을 확보하되 작은 연구에서는 최대 절반, 항목이 1,000개를 넘는 연구에서는 최대 5분의 1로 제한합니다. |
dev_fraction | 0.5 | 보정 레이블 중 임계값을 고르는 데 쓰는 비율입니다. 나머지로 임계값을 검정합니다. |
min_calibration_per_class | 10 | 클래스별 계약을 검정하기 전에 필요한 클래스당 최소 개수입니다. |
audit_rate | 0.02 | 새로 수락된 기계 레이블 중 드리프트를 감시하기 위해 블라인드로 다시 사람에게 보내는 비율입니다. |
overlap | 0.0 | 보정 항목 중 여러 사람이 레이블을 다는 비율입니다. |
overlap_k | 3 | 중복 항목당 사람 수입니다. no_worse_than_human 계약에는 3이 필요합니다. |
distribution_k | 5 | distributional 계약에서 항목당 사람 수입니다. |
truth | majority | 한 항목에 대한 여러 사람의 레이블을 계약이 검정 기준으로 삼는 레이블로 만드는 방식으로, majority 또는 dawid_skene입니다. |
verify_visibility | shown | 검증 요청에서 기계의 답을 보여 줄지(shown) 보여 주지 않을지(blind)입니다. |
crowd
crowd 블록은 humans.pools에 crowd가 있을 때 적용되며, 엔진이 구동할 수 있는 크라우드 플랫폼은 Prolific뿐입니다.
| 키 | 기본값 | 의미 |
|---|---|---|
provider | prolific | 크라우드 플랫폼입니다. |
study_id | 없음 | 규모를 조정할 Prolific 연구입니다. |
reward_usd | 없음 | 비용 추정에 쓰는 자리당 보상입니다. |
per_worker_quota | 20 | 작업자당 요청 수입니다. 자리 수는 ceil(open requests / quota)입니다. |
크라우드 모집은 기본적으로 시험 실행(dry run)이며, 플래너는 무엇을 할지 보고만 합니다. 실제로 돈을 쓰려면 features.crowd_live_spend: true와 budgets.human_usd 상한이 필요하며, 상한 없이 실제 지출을 켠 설정은 거부됩니다. Prolific 연구 자체를 설정하는 방법은 크라우드소싱에서 다룹니다.
budgets
budgets 블록은 한도를 넘기 전에 지출을 멈춥니다.
| 키 | 의미 |
|---|---|
model_usd | 이만큼 쓰면 유료 모델 호출을 멈춥니다. 각 호출은 먼저 예상 비용을 예약합니다. 가격이 없는 모델과 localhost의 자체 호스팅 모델은 이 한도의 제한을 받지 않습니다. |
human_usd | 크라우드 지출 상한입니다. 실제 크라우드 지출에 필수입니다. |
human_labels | 엔진이 열 수 있는 사람 요청의 최대 수로, 각 요청을 열 때 셉니다. |
runtime
runtime 블록은 배치 처리, 동시성, 사람이 요청을 맡고 있을 수 있는 시간을 제어합니다.
| 키 | 기본값 | 의미 |
|---|---|---|
batch_size | 32 | 커밋되는 덩어리당 항목 수입니다. 중단된 실행은 호출을 반복하지 않고 다음 덩어리부터 재개됩니다. |
concurrency | 4 | 소스당 병렬 호출 수이며, 소스 자체의 concurrency가 이를 덮어씁니다. |
cache | true | 같은 소스 버전에 대한 동일한 요청의 답을 재사용합니다. |
retries | 2 | 타임아웃, 연결 오류, 429, 5xx 뒤의 추가 시도 횟수입니다. 모든 시도가 기록됩니다. |
planner_interval | 30 | 서버에서 플래너 실행 사이의 초 단위 간격입니다. |
hold_minutes | 60 | 사람이 답하지 않고 요청을 맡고 있을 수 있는 분 단위 시간으로, 이 시간이 지나면 요청은 풀로 돌아갑니다. 항목도 그 사람의 페이지에서 사라지므로, 열어 둔 탭이 나중에 답할 수는 없습니다. |
features
drift를 제외한 모든 기능은 기본으로 꺼져 있습니다.
| 키 | 켜는 기능 |
|---|---|
drift | 기본으로 켜져 있습니다. 감사 결과에 따라 조치합니다. 감사 결과 수락된 레이블의 오류율이 목표보다 높으면 계약은 violated가 되고, 그 스키마에서 기계 레이블을 더 이상 수락하지 않으며, 새 보정 레이블을 뽑습니다. 인증할 때마다 새 감사 순서가 시작되므로, 문제를 고친 뒤 다시 인증하면 수락이 복원됩니다. false로 설정하면 위반을 보고만 하며, 이때 계약은 "met, audits breached"로 표시됩니다. |
distill | 연구의 레이블로 모델을 학습시켜 캐스케이드 맨 앞에 둡니다(distill 참고). |
optimize | 플래너가 실행될 때마다 캐스케이드의 모든 부분집합을 dev 레이블로 채점하고, 계약의 커버리지를 유지하는 가장 저렴한 조합을 GET /api/engine/v1/schemes/<name>/optimize에 보고합니다. 캐스케이드를 채택하는 것은 설정 변경이자 새 인증이므로, 아무것도 적용되지 않습니다. |
crowd_recruit | 플래너가 Prolific 연구의 규모를 정하게 합니다. crowd_live_spend가 켜져 있지 않으면 시험 실행입니다. |
crowd_live_spend | Prolific 연구를 실제로 변경합니다. crowd 풀과 budgets.human_usd가 필요합니다. |
pii_redaction | 텍스트가 제3자 API로 가기 전에 이메일, URL, IP 주소, 카드 번호, SSN, 전화번호, @핸들을 가립니다. 호출 로그에는 가린 내용이 텍스트가 아니라 범주와 해시로만 기록됩니다. |
payload_capture | 전체 프롬프트와 답을 <task_dir>/engine_payloads/ 아래에 보관합니다. 기본으로 꺼져 있으며, 호출 로그에는 해시만 남습니다. |
redaction
redaction.categories는 email, url, ip, card, ssn, phone, handle 중 무엇을 가릴지 나열하며, 기본값은 전부입니다. 가리기는 features.pii_redaction이 켜져 있을 때만, 그리고 제3자 API에만 적용됩니다. 자체 호스팅 엔드포인트 유형(vllm, ollama, laya, yolo, ...)은 어디서 실행되든 가리지 않으며, base_url이 같은 컴퓨터에 있는 엔드포인트도 가리지 않습니다.
distill
features.distill을 켜면 엔진은 연구의 레이블로 저렴한 모델을 학습시켜 캐스케이드 맨 앞에 둡니다.
| 키 | 기본값 | 의미 |
|---|---|---|
trainer | sklearn-text | potato/training의 트레이너입니다. |
min_labels | 200 | 레이블이 이만큼 있어야 학습합니다. |
include_silver | true | 계약이 인증한 기계 레이블도 silver로 표시해 학습에 씁니다. |
every | 2.0 | 레이블 수가 이 배수만큼 늘어나면 다시 학습합니다. |
cert 분할과 감사 분할의 항목은 절대 학습 세트에 들어가지 않으므로, 증류 모델은 자신이 학습한 레이블로 검정받는 일이 없습니다.
검증
potato validate config.yaml은 설정의 나머지 부분과 함께 labeling_engine 블록을 검사하며, 각 오류는 해당 키를 짚습니다. 예를 들면 labeling_engine.sources[1].kind must be one of ... 또는 labeling_engine.contracts[0].error is required for selective_risk와 같습니다. 검증은 다음도 거부합니다.
- 해당 계약 종류가 읽지 않는 계약 키(예:
error의 오타) - 어떤 캐스케이드 소스도 레이블을 달 수 없는 스키마에 대한 계약(각 소스의 이유와 함께)
- 엔진이 채점할 수 없는 스키마(자유 텍스트, 쌍대 비교)에 대한 계약
endpoint_type이 의사결정 모델이 아닌decision소스, 그리고endpoint_type이 의사결정 모델인llm,vlm,judge소스humans.overlap_k가 3보다 작은no_worse_than_human
검증은 또한 기계의 답이 모두 맞더라도 budgets.human_labels가 너무 작아 selective_risk 계약을 인증할 수 없을 때 경고합니다. 그 경고가 사라질 때까지 예산을 늘리거나 error를 완화하세요.
더 읽어보기
- 레이블링 엔진
- 레이블링 엔진 계약
- 명령줄, REST API, MCP 도구, SDK
- 소스가 Potato의 나머지 부분과 공유하는 엔드포인트 유형을 다루는 AI 지원
구현에 관한 자세한 내용은 소스 문서를 참고하세요.