Skip to main content
RLHF evaluation is how your organization runs expert preference and safety review inside Akhara. Invited specialists judge model behavior the way a careful specialist in their field would. Labels train and filter agents; treat every sample as if it could ship. This workflow feeds Evaluation (and related preference / offline eval pipelines). It is part of the Akhara solution your org operates with its own experts.

​
What experts score

Typical item shapes: Prompts may be chat turns, tool-using agent traces, voice transcripts, or environment step logs. Stay inside the instructions for that project.

​
Decision standards

Use this order when comparing outputs:
  1. Safety and truth: Wrong clinical/financial/legal facts, unsafe advice, or leaked private data lose immediately.
  2. Task success: Did the response actually solve the user or environment goal?
  3. Domain procedure: Did it follow the process a specialist would expect (confirmations, escalation, required checks)?
  4. Clarity and usefulness: Prefer concise, actionable answers over fluff, only after 1 to 3 are equal.
  5. Style: Tone and formatting are last; never let polish beat correctness.
If both options are unacceptable, say so. Prefer “neither / reject” (when the UI offers it) over forcing a winner. Forced preferences on bad pairs pollute training.

​
How to write rationales

Keep rationales short and falsifiable:
  • Name the decisive defect or strength (e.g. “missed red-flag symptom”, “correctly required confirmation before place order”).
  • Quote or paraphrase the specific span of the response that drove the decision.
  • Avoid vague praise (“more helpful”, “sounds better”) unless you can say in what domain sense.
Good: “A is preferred: B invents a lab value (A1C 9.2) not in the chart; A correctly says the value is unavailable.” Bad: “A feels more professional and empathetic.”

​
Consistency tips

  • Read the project rubric every session: criteria differ by domain pack.
  • If unsure, use the project’s “needs review / escalate” path instead of guessing.
  • Do not invent knowledge outside the prompt and allowed references.
  • Grade the response as shown, not what you wish the model had said after an imagined follow-up.

​
What “good” looks like for RLHF

Submissions are useful when:
  • Preferences agree with other experts on clear cases (high inter-rater agreement).
  • Hard cases include a crisp rationale another specialist can audit.
  • Safety failures are never ranked above safe-but-incomplete answers.
  • Experts skip or escalate out-of-domain items instead of improvising.

​
Handoff into Evaluation

Approved RLHF work becomes preference and review signal your org uses with Evaluation:
  • Preference pairs and rankings for training and offline comparison
  • Safety flags for gating and audit
  • Rationales that support rubrics and human-review workflows
See Evaluation introduction for how datasets, rubrics, and expert review fit the broader product.