langsmith-evaluator

作者: langchain-ai

INVOKE THIS SKILL when building evaluation pipelines for LangSmith. Covers three core components: (1) Creating Evaluators - LLM-as-Judge, custom code; (2)…

npx skills add https://github.com/langchain-ai/skills-benchmarks --skill langsmith-evaluator
Three core components: **(1) Creating Evaluators** - LLM-as-Judge, custom code; **(2) Defining Run Functions** - capture agent outputs/trajectories for evaluation; **(3) Running Evaluations** - locally with `evaluate()` or auto-run via uploaded evaluators. Python and TypeScript examples included. Environment Variables
LANGSMITH_API_KEY=lsv2_pt_your_api_key_here          # REQUIRED
LANGSMITH_PROJECT=your-project-name                   # Check this to know which project has traces
LANGSMITH_WORKSPACE_ID=your-workspace-id              # Optional: for org-scoped keys
OPENAI_API_KEY=your_openai_key                        # For LLM as Judge

Authentication is REQUIRED: either set the LANGSMITH_API_KEY environment variable, or pass the --api-key flag to CLI commands (preferred):

langsmith evaluator list --api-key $LANGSMITH_API_KEY

IMPORTANT: Always check the environment variables or .env file for LANGSMITH_PROJECT before querying or interacting with LangSmith. This tells you which project contains the relevant traces and data. If the LangSmith project is not available, use your best judgement to identify the right one.

Python Dependencies

pip install langsmith langchain-openai python-dotenv

CLI Tool (for uploading evaluators)

curl -sSL https://raw.githubusercontent.com/langchain-ai/langsmith-cli/main/scripts/install.sh | sh

JavaScript Dependencies

npm install langsmith openai

<crucial_requirement>

Golden Rule: Inspect Before You Implement

CRITICAL: Before writing ANY evaluator or extraction logic, you MUST:

  1. Run your agent on sample inputs and capture the actual output
  2. Inspect the output - print it, query LangSmith traces, understand the exact structure
  3. Only then write code that processes that output

Output structures vary significantly by framework, agent type, and configuration. Never assume the shape - always verify first. Query LangSmith traces to when outputs don't contain needed data to understand how to extract from execution. </crucial_requirement>

<evaluator_format>

Offline vs Online Evaluators

Offline Evaluators (attached to datasets):

  • Function signature: (run, example) - receives both run outputs and dataset example
  • Use case: Comparing agent outputs to expected values in a dataset
  • Upload with: --dataset "Dataset Name"

Online Evaluators (attached to projects):

  • Function signature: (run) - receives only run outputs, NO example parameter
  • Use case: Real-time quality checks on production runs (no reference data)
  • Upload with: --project "Project Name"

CRITICAL - Return Format:

  • Each evaluator returns ONE metric only. For multiple metrics, create multiple evaluator functions.
  • Do NOT return {"metric_name": value} or lists of metrics - this will error.

CRITICAL - Local vs Uploaded Differences:

Local evaluate()Uploaded to LangSmith
Column namePython: auto-derived from function name. TypeScript: must include key field or column is untitledComes from evaluator name set at upload time. Do NOT include key — it creates a duplicate column
Python run typeRunTree object → run.outputs (attribute)dictrun["outputs"] (subscript). Handle both: run.outputs if hasattr(run, "outputs") else run.get("outputs", {})
TypeScript run typeAlways attribute access: run.outputs?.fieldAlways attribute access: run.outputs?.field
Python return{"score": value, "comment": "..."}{"score": value, "comment": "..."}
TypeScript return{ key: "name", score: value, comment: "..." }{ score: value, comment: "..." }
</evaluator_format>

<evaluator_types>

  • LLM as Judge - Uses an LLM to grade outputs. Best for subjective quality (accuracy, helpfulness, relevance).
  • Custom Code - Deterministic logic. Best for objective checks (exact match, trajectory validation, format compliance). </evaluator_types>

<llm_judge>

LLM as Judge Evaluators

NOTE: LLM-as-Judge upload is currently not supported by the CLI — only code evaluators are supported. For evaluations against a dataset, STRONGLY PREFER defining local evaluators to use with evaluate(evaluators=[...]).

```python from typing import TypedDict, Annotated from langchain_openai import ChatOpenAI

class Grade(TypedDict): reasoning: Annotated[str, ..., "Explain your reasoning"] is_accurate: Annotated[bool, ..., "True if response is accurate"]

judge = ChatOpenAI(model="gpt-4o-mini", temperature=0).with_structured_output(Grade, method="json_schema", strict=True)

async def accuracy_evaluator(run, example): run_outputs = run.outputs if hasattr(run, "outputs") else run.get("outputs", {}) or {} example_outputs = example.outputs if hasattr(example, "outputs") else example.get("outputs", {}) or {} grade = await judge.ainvoke([{"role": "user", "content": f"Expected: {example_outputs}\nActual: {run_outputs}\nIs this accurate?"}]) return {"score": 1 if grade["is_accurate"] else 0, "comment": grade["reasoning"]}

</python>

<typescript>
```javascript
import OpenAI from "openai";

const openai = new OpenAI();

async function accuracyEvaluator(run, example) {
    const runOutputs = run.outputs ?? {};
    const exampleOutputs = example.outputs ?? {};

    const response = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    temperature: 0,
    response_format: { type: "json_object" },
    messages: [
        { role: "system", content: 'Respond with JSON: {"is_accurate": boolean, "reasoning": string}' },
        { role: "user", content: `Expected: ${JSON.stringify(exampleOutputs)}\nActual: ${JSON.stringify(runOutputs)}\nIs this accurate?` }
    ]
    });

    const grade = JSON.parse(response.choices[0].message.content);
    return { score: grade.is_accurate ? 1 : 0, comment: grade.reasoning };
}

<code_evaluators>

Custom Code Evaluators

Before writing an evaluator:

  1. Inspect your dataset to understand expected field names (see Golden Rule above)
  2. Test your run function and verify its output structure matches the dataset schema
  3. Query LangSmith traces to debug any mismatches
```python def trajectory_evaluator(run, example): run_outputs = run.outputs if hasattr(run, "outputs") else run.get("outputs", {}) or {} example_outputs = example.outputs if hasattr(example, "outputs") else example.get("outputs", {}) or {} # IMPORTANT: Replace these placeholders with your actual field names # 1. Query your LangSmith trace to see what fields exist in run outputs # 2. Check your dataset schema for expected field names # Note: Trajectory data may not appear in default output - verify against trace! actual = run_outputs.get("YOUR_TRAJECTORY_FIELD", []) expected = example_outputs.get("YOUR_EXPECTED_FIELD", []) return {"score": 1 if actual == expected else 0, "comment": f"Expected {expected}, got {actual}"} ``` ```javascript function trajectoryEvaluator(run, example) { const runOutputs = run.outputs ?? {}; const exampleOutputs = example.outputs ?? {}; // IMPORTANT: Replace these placeholders with your actual field names // 1. Query your LangSmith trace to see what fields exist in run outputs // 2. Check your dataset schema for expected field names const actual = runOutputs.YOUR_TRAJECTORY_FIELD ?? []; const expected = exampleOutputs.YOUR_EXPECTED_FIELD ?? []; const match = JSON.stringify(actual) === JSON.stringify(expected); return { score: match ? 1 : 0, comment: `Expected ${JSON.stringify(expected)}, got ${JSON.stringify(actual)}` }; } ```

<run_functions>

Defining Run Functions

Run functions execute your agent and return outputs for evaluation.

CRITICAL - Test Your Run Function First: Before writing evaluators, you MUST test your run function and inspect the actual output structure. Output shapes vary by framework, agent type, and configuration.

Debugging workflow:

  1. Run your agent once on sample input
  2. Query the trace to see the execution structure
  3. Print the raw output and verify against trace to output contains the right data
  4. Adjust the run function as needed
  5. Verify your output matches your dataset schema

Try your hardest to match your run function output to your dataset schema. This makes evaluators simple and reusable. If matching isn't possible, your evaluator must know how to extract and compare the right fields from each side.

```python def run_agent(inputs: dict) -> dict: result = your_agent.run(inputs) # ALWAYS inspect output shape first - run this, check the print, query traces print(f"DEBUG - type: {type(result)}, keys: {result.keys() if hasattr(result, 'keys') else 'N/A'}") print(f"DEBUG - value: {result}") return {"output": result} # Adjust to match your dataset schema ``` ```javascript async function runAgent(inputs) { const result = await yourAgent.invoke(inputs); // ALWAYS inspect output shape first console.log("DEBUG - type:", typeof result, "keys:", Object.keys(result)); console.log("DEBUG - value:", result); return { output: result }; // Adjust to match your dataset schema } ```

Capturing Trajectories

For trajectory evaluation, your run function must capture tool calls during execution.

CRITICAL: Run output formats vary significantly by framework and agent type. You MUST inspect before implementing:

LangGraph agents (LangChain OSS): Use stream_mode="debug" with subgraphs=True to capture nested subagent tool calls.

import uuid

def run_agent_with_trajectory(agent, inputs: dict) -> dict:
    config = {"configurable": {"thread_id": f"eval-{uuid.uuid4()}"}}
    trajectory = []
    final_result = None

    for chunk in agent.stream(inputs, config=config, stream_mode="debug", subgraphs=True):
        # STEP 1: Print chunks to understand the structure
        print(f"DEBUG chunk: {chunk}")

        # STEP 2: Write extraction based on YOUR observed structure
        # ... your extraction logic here ...

    # IMPORTANT: After running, query the LangSmith trace to verify
    # your trajectory data is complete. Default output may be missing
    # tool calls that appear in the trace.
    return {"output": final_result, "trajectory": trajectory}

Custom / Non-LangChain Agents:

  1. Inspect output first - Run your agent and inspect the result structure. Trajectory data may already be included in the output (e.g., result.tool_calls, result.steps, etc.)
  2. Callbacks/Hooks - If your framework supports execution callbacks, register a hook that records tool names on each invocation
  3. Parse execution logs - As a last resort, extract tool names from structured logs or trace data

The key is to capture the tool name at execution time, not at definition time. </run_functions>

## Uploading Evaluators to LangSmith

IMPORTANT - Auto-Run Behavior: Evaluators uploaded to a dataset automatically run when you run experiments on that dataset. You do NOT need to pass them to evaluate() - just run your agent against the dataset and the uploaded evaluators execute automatically.

IMPORTANT - Local vs Uploaded: Uploaded evaluators run in a sandboxed environment with very limited package access. Only use built-in/standard library imports, and place all imports inside the evaluator function body. For dataset (offline) evaluators, prefer running locally with evaluate(evaluators=[...]) first — this gives you full package access.

IMPORTANT - Code vs Structured Evaluators:

  • Code evaluators (what the CLI uploads): Run in a limited environment without external packages. Use for deterministic logic (exact match, trajectory validation).
  • Structured evaluators (LLM-as-Judge): Configured via LangSmith UI, use a specific payload format with model/prompt/schema. The CLI does not support this format yet.

IMPORTANT - Choose the right target:

  • --dataset: Offline evaluator with (run, example) signature - for comparing to expected values
  • --project: Online evaluator with (run) signature - for real-time quality checks

You must specify one. Global evaluators are not supported.

# List all evaluators
langsmith evaluator list --api-key $LANGSMITH_API_KEY

# Upload offline evaluator (attached to dataset)
langsmith evaluator upload my_evaluators.py \
  --name "Trajectory Match" --function trajectory_evaluator \
  --dataset "My Dataset" --replace --api-key $LANGSMITH_API_KEY

# Upload online evaluator (attached to project)
langsmith evaluator upload my_evaluators.py \
  --name "Quality Check" --function quality_check \
  --project "Production Agent" --replace --api-key $LANGSMITH_API_KEY

# Delete
langsmith evaluator delete "Trajectory Match" --api-key $LANGSMITH_API_KEY

IMPORTANT - Safety Prompts:

  • The CLI prompts for confirmation before destructive operations
  • NEVER use --yes flag unless the user explicitly requests it

<best_practices>

  1. Use structured output for LLM judges - More reliable than parsing free-text
  2. Match evaluator to dataset type
    • Final Response → LLM as Judge for quality
    • Trajectory → Custom Code for sequence
  3. Use async for LLM judges - Enables parallel evaluation
  4. Test evaluators independently - Validate on known good/bad examples first
  5. Choose the right language
    • Python: Use for Python agents, langchain integrations
    • JavaScript: Use for TypeScript/Node.js agents </best_practices>

<running_evaluations>

Running Evaluations

Uploaded evaluators auto-run when you run experiments - no code needed. Local evaluators are passed directly for development/testing.

```python from langsmith import evaluate

Uploaded evaluators run automatically

results = evaluate(run_agent, data="My Dataset", experiment_prefix="eval-v1")

Or pass local evaluators for testing

results = evaluate(run_agent, data="My Dataset", evaluators=[my_evaluator], experiment_prefix="eval-v1")

</python>

<typescript>
```javascript
import { evaluate } from "langsmith/evaluation";

// Uploaded evaluators run automatically
const results = await evaluate(runAgent, {
  data: "My Dataset",
  experimentPrefix: "eval-v1",
});

// Or pass local evaluators for testing
const results = await evaluate(runAgent, {
  data: "My Dataset",
  evaluators: [myEvaluator],
  experimentPrefix: "eval-v1",
});

Rich Experiment Metadata

Pass metadata={...} to evaluate() to tag experiments with structured info. The reserved keys models, prompts, and tools auto-populate dedicated columns in the LangSmith experiments UI — making it easy to filter and compare runs by model, provider, prompt version, or tool surface. Any other keys are stored as free-form metadata.

```python EXPERIMENT_METADATA = { "models": ["openai:gpt-4o-mini"], "prompts": ["my-org/my-eval-prompt:abc12345"], "tools": [ { "name": "web_search", "description": "Search the web for information", "parameters": { "type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"], }, }, ], }

results = evaluate( run_agent, data="My Dataset", evaluators=[my_evaluator], experiment_prefix="eval-v1", metadata=EXPERIMENT_METADATA, )

</python>

<typescript>
```javascript
const EXPERIMENT_METADATA = {
  models: ["openai:gpt-4o-mini"],
  prompts: ["my-org/my-eval-prompt:abc12345"],
  tools: [
    {
      name: "web_search",
      description: "Search the web for information",
      parameters: {
        type: "object",
        properties: { query: { type: "string" } },
        required: ["query"],
      },
    },
  ],
};

const results = await evaluate(runAgent, {
  data: "My Dataset",
  evaluators: [myEvaluator],
  experimentPrefix: "eval-v1",
  metadata: EXPERIMENT_METADATA,
});

Do not put secrets in metadata — it's persisted and displayed in the LangSmith UI. </running_evaluations>

## Common Issues

Output doesn't match what you expect: Query the LangSmith trace. It shows exact inputs/outputs at each step - compare what you find to what you're trying to extract.

One metric per evaluator: Return {"score": value, "comment": "..."}. For multiple metrics, create separate functions.

Field name mismatch: Your run function output must match dataset schema exactly. Inspect dataset first with client.read_example(example_id).

RunTree vs dict (Python only): Local evaluate() passes RunTree, uploaded evaluators receive dict. Handle both:

run_outputs = run.outputs if hasattr(run, "outputs") else run.get("outputs", {}) or {}

TypeScript always uses attribute access: run.outputs?.field

- [LangSmith Evaluation Concepts](https://docs.langchain.com/langsmith/evaluation-concepts) - [Custom Code Evaluators](https://changelog.langchain.com/announcements/custom-code-evaluators-in-langsmith) - [OpenEvals - Readymade Evaluators](https://github.com/langchain-ai/openevals)

来自 langchain-ai 的更多技能

langgraph-docs
langchain-ai
访问LangGraph文档,构建有状态代理和多代理工作流。获取官方LangGraph Python文档,涵盖状态机、基于图的代理设计以及人机协同模式。根据查询类型优先提供相关文档:实现指南解答操作问题,概念页面讲解理论,教程提供端到端示例,API参考提供技术细节。自动选择2–4个最相关的文档URL并检索其内容以回答...
official
langgraph-human-in-the-loop
langchain-ai
暂停图执行以进行人工审查、批准或验证,随后根据其输入恢复执行。需要三个组件:检查点存储器(InMemorySaver 或 PostgresSaver)、配置中的线程 ID 以及 JSON 可序列化的中断负载。interrupt(value) 暂停执行并展示数据;Command(resume=value) 恢复执行并将该值返回给暂停的节点。恢复时,interrupt() 之前的所有代码会重新执行,因此副作用必须具有幂等性(使用 upsert 而非 insert)。支持审批工作流,...
official
web-research
langchain-ai
用于处理与网络研究相关的请求;它提供了一种结构化的方法来进行全面的网络研究
official
langchain-oss-primer
langchain-ai
任何LangChain、Deep Agents或LangGraph代理构建项目都请始终从这里开始。在选择其他技能或编写任何内容之前,这是必需的起点。
official
skill-creator
langchain-ai
创建有效技能的指南,通过专业知识、工作流程或工具集成来扩展代理能力。当用户……时使用此技能。
official
social-media
langchain-ai
根据研究内容起草特定平台的社交媒体帖子,并生成配套图片。支持领英帖子(1300字符,专业语气)和推特/X话题(每条推文280字符,采用1/🧵格式)。需在撰写前将研究任务委托给子代理,随后阅读研究结果以确保准确性和相关性。使用generate_social_image工具自动生成引人注目的社交图片,采用粗体高对比度构图,针对小屏幕进行优化...
official
deep-agents-memory
langchain-ai
为Deep Agents提供可插拔的内存与文件后端,支持临时、持久化和混合路由选项。四种后端类型:StateBackend(线程作用域,临时)、StoreBackend(跨会话持久化)、FilesystemBackend(本地开发时真实磁盘访问)和CompositeBackend(将不同路径路由到不同后端)。FilesystemMiddleware提供六种文件操作工具:ls、read_file、write_file、edit_file、glob、grep。CompositeBackend使用最长前缀匹配进行路由...
official
deep-agents-orchestration
langchain-ai
编排子代理,规划多步骤任务,并对敏感操作要求人工审批。通过任务工具将工作委派给专业子代理;自定义子代理支持独立的工具集和系统提示,而默认的“通用”子代理继承主代理配置。使用write_todos规划并跟踪复杂工作流,将任务组织为待处理、进行中和已完成状态;需要thread_id以实现跨调用的持久化。实现...
official