Obsidian Metadata
| type | concept |
| sources | Source - AI Evals FAQ, Source - A Field Guide to Rapidly Improving AI Products |
Team Collaboration on Evals
PMs × engineers on error analysis
- At the outset, collaborate to build shared context. Engineers catch technical issues (retrieval problems, tool errors). PMs catch product failures (unmet expectations, confusing responses, missing features).
- Over time, move toward a Benevolent Dictator: a domain expert or PM who understands user needs.
- Have experts evaluate outcomes, not implementation: “Has an appointment been made?” not “Did the tool call succeed?”
- Give them custom tools that show system outcomes next to traces (the confirmation, generated email, DB update), with all context on one screen.
Can non-domain-experts help? Yes, especially early.
Low-hanging fruit an outsider can find without domain knowledge:
- SMS bots confused by many short, broken-up messages (texting behavior vs chat).
- No disambiguation or follow-up when requests are obviously vague.
- Missing instrumentation, logging, or traces.
- Missing widgets or UI affordances, with too much reliance on text replies.
Also:
- Ask an expert to walk through an example and explain good or bad. Watch what they check and what evidence they need, then build a better annotation interface from that.
- Help collect interactions and run regular reviews.
- Leave specialized judgments to the expert, but don’t assume you need domain expertise to be useful.
Empower domain experts to write prompts
“Prompts are just English.” Engineers translating a learning designer’s PowerPoint into prompts adds friction. Give experts prompt playgrounds and, better, integrated prompt environments: admin versions of the real UI with prompt editing, running against real RAG and tools (see Prompt Management).
Settle responsibility vs accountability
Three questions every team should answer explicitly (Video - How Engineers and PMs Should Collaborate on Evals):
- How many labels, and what agreement is required? (e.g., the engineer accountable for eval quality sets N, and the PM is responsible for getting the labels)
- Eval says good, human says bad: who reviews and who breaks the tie?
- Eval says good, business metric drops: the PM owns the outcome, so correlate eval scores, human labels, and business metrics in one place. Labels and judge prompts are intertwined, so PMs should be close to both.
Drop the jargon
| Instead of… | Say… |
|---|---|
| ”We’re implementing a RAG approach" | "We’re making sure the model has the right context to answer questions" |
| "We need to prevent prompt injection" | "We need to make sure users can’t trick the AI into ignoring our rules" |
| "Our model suffers from hallucination issues" | "Sometimes the AI makes things up, so we need to check its answers” |
Be precise about what you’re doing: is “building an agent” really function calling, tool use, or just a better prompt? Adapt terminology to your audience.
Related
Making the Case for Evals · Benevolent Dictator · Internal Eval Platforms