RLHF and preference-tuning pipelines all hit the same bottleneck before the math even starts: you need a steady stream of real human judgments on model outputs — which completion is better, how good is this response, what's wrong with it — and you need it in a shape you can feed straight into training. Standing up an annotation team for that is a project in itself. GetABrain turns it into an API call: submit the comparison or rating, real people answer, you get structured, quality-scored responses back.
The three shapes RLHF work actually needs
Preference-tuning data isn't one thing — it's usually a mix of these, and the API supports each as a distinct query type rather than forcing everything through free text:
- ab_comparison — the classic RLHF pairwise preference: show two model completions for the same prompt, ask which is better (and why, optionally). This is the core signal DPO/RLHF reward models train on.
- rating_scale — score a single output on a defined scale (helpfulness, correctness, tone) when you need magnitude, not just a winner.
- free_text / structured text — open-ended critique, useful for building rationale datasets or a qualitative pass before scaling up the graded types.
Why this beats building your own labeling pipeline
The honest alternatives are Mechanical Turk, Scale, Prolific, or an in-house Slack/spreadsheet loop. All three work; all three also mean you're managing recruiting, qualification, and payout logic instead of collecting data. GetABrain's workers already carry a quality score and tier, and you can gate a query to min_worker_quality so preference data only comes from proven-reliable raters — the same lever RLHF teams reach for manually when they filter out noisy annotators after the fact.
The other difference is speed of iteration: because a test-mode key returns synthetic-but-correctly-shaped responses instantly, you can build and unit-test your whole ingestion pipeline (parsing, aggregation, reward-model input formatting) before a single real dollar or real rater is involved.
What comes back
Every response includes the structured answer for the query type, the worker's quality tier at time of response, and a timestamp — enough to build inter-rater agreement checks or a majority-vote aggregation without any extra plumbing. rate_response lets you score the rating itself after the fact, which both filters bad raters over time and gives you a second, meta-quality signal if your pipeline wants one.
POST /api/v1/queries
{
"type": "ab_comparison",
"title": "Which response better answers the user's question?",
"content_data": {
"prompt": "Explain why the sky is blue, for a 10 year old.",
"option_a": "<completion from model checkpoint A>",
"option_b": "<completion from model checkpoint B>"
},
"required_responses": 5,
"min_worker_quality": 4.0,
"bid_amount_cents": 20
}
// -> { "query_id": "q_...", "status": "open" }
GET /api/v1/queries/{query_id}/responses
// -> {
// "responses": [
// { "answer": "b", "rationale": "more concrete, avoids jargon", "worker_quality_tier": "gold", "created_at": "..." },
// ...
// ]
// }