AIYINGFrom AI Awareness to Accomplishment
Showing posts with label Evaluation. Show all posts
Showing posts with label Evaluation. Show all posts

Monday, November 9, 2026

AI Engineering Principle 003: Turn Real Failures into Better Tests

AI Engineering Principles & Practice · Post 003

Turn Real Failures into Better Tests

A failure is more than a bug to fix. It can become a test that helps catch the same problem next time.


The principle

When an AI system gives an unsupported answer, misses a user’s intent, or uses a tool when it should not, save the example. Turn it into a repeatable test.

A test case should capture the situation that caused the failure, the behavior you expected, and how you will judge whether the system handled it correctly. After changing the prompt, model, tools, or workflow, run the test again. This helps you see whether the change fixed the problem and whether it affected other cases.

This creates a practical learning loop: observe a failure, understand what went wrong, add a test, improve the system, and check the result.

Back to top ↑

A practical example: a course handbook assistant

Imagine an assistant that answers questions using a course handbook. A learner asks about a deadline, but the assistant gives a date that does not appear in the handbook.

Turn that incident into a test case:

  • Input: Ask the same question about the deadline.
  • Expected behavior: The assistant should use a supported date or say that the handbook does not provide one.
  • Evidence: Check whether the response is supported by the relevant handbook passage.
  • Pass condition: The assistant does not invent a date.

The next time the system changes, rerun this case. If the assistant now answers correctly, the test guards against a known failure returning.

Back to top ↑

Keep the test set balanced

A test set made only from past failures can push the system too strongly toward avoiding those failures. Include a mix of examples:

  • Common tasks: Questions the system should answer well.
  • Edge cases: Ambiguous or unusually phrased requests.
  • Should-not-do cases: Requests where the system should not guess, search, or take an action.
  • Known failures: Real examples that previously produced a poor result.

For example, test both when a handbook assistant should search for a specific course rule and when it should answer directly from information already available. This checks that the system does not simply search every time—or skip searching when it is needed.

Anthropic suggests that 20–50 simple tasks drawn from real failures can be a useful starting point for early agent development. Treat this as a practical starting suggestion, not a fixed requirement: a mature system may need broader and more challenging coverage.

Back to top ↑

Independent study exercise

Choose an AI assistant or feature you use. Create four test cases:

  1. A typical request the system should handle.
  2. A difficult or ambiguous request.
  3. A request that previously produced a poor response, if you have one.
  4. A request where the system should ask for clarification, decline, or avoid guessing.

For each case, write down:

  • The input you will use.
  • The expected behavior.
  • The evidence you will check.
  • What would count as a pass or failure.

Keep the set and add new cases as you discover failures. Use examples you are authorized to work with, and remove personal or confidential details before using them in shared materials.

Engineering takeaway: Turn real failures into repeatable tests, and keep the test set balanced.

Back to top ↑

Research basis

  • Anthropic, “Demystifying Evals for AI Agents” (January 9, 2026). The article recommends starting with a manageable set of tasks drawn from real failures, balancing cases where a behavior should and should not occur, and adding examples as coverage improves.
  • OpenAI, “Evaluation Best Practices”. The guide recommends task-specific tests that reflect real-world distributions, using development logs to find evaluation cases, and growing the set over time.

This post is an independent study reference based on publicly available engineering material. It is not an official guide or endorsement from the cited organizations.

AIYING — Accomplishing with AI
AI Engineering Principles & Practice · 003

AI Engineering Principle 002: Check the Work, Not Just the Words

AI Engineering Principles & Practice · Post 002

Check the Work, Not Just the Words

When an AI system uses tools or changes data, its final response is only one part of the evidence. Verify the result—and inspect the activity trace when the actions matter.



The principle

An AI agent can say “Done” without completing the task. It can also complete an important step without mentioning it in the final response.

For systems that call tools, retrieve information, or change an external state, evaluate more than the wording of the final answer. Check whether the intended outcome actually occurred. When the process itself matters—for example, whether the agent checked a source, used the correct tool, or respected a restriction—inspect the recorded actions as well.

The record of an agent’s run may include its messages, tool calls, and intermediate results. The final state of the environment provides separate evidence of what changed. These views answer different questions: what the agent did, and whether the task was accomplished.

Back to top ↑

A practical example: updating a support ticket

Imagine an AI agent is asked to update a customer’s support ticket after a refund has been approved. Its final response says, “The ticket has been updated.”

That response alone does not establish that the task succeeded. Check evidence such as:

  • Was the correct ticket opened?
  • Did the system record the approved refund or update?
  • Was the permitted tool used?
  • Did the agent avoid making an unapproved change?
  • Does the final response accurately describe the recorded result?

The checks should match the task. If the requirement is that a record changed, verify the record. If the requirement includes a required approval or safety step, inspect evidence that the step occurred.

Back to top ↑

Evaluate the outcome without overconstraining the path

Google Cloud described an evaluation where a grader marked three of eleven prompts as failures because the agent’s final responses did not mention required checks. Review of the tool-call logs showed that the agent had performed those checks. This illustrates why a final-message-only evaluation can miss relevant behavior.

At the same time, a test can be too rigid if it requires one exact sequence of tool calls. An agent may reach the correct, safe result through another valid route. A useful evaluation checks the required outcome and any actions that genuinely matter, while allowing reasonable alternatives.

Engineering takeaway: Verify the result. Inspect the trace when the process matters. Allow valid paths to differ.

Back to top ↑

Independent study exercise

Choose a task for an AI system that uses a tool or changes information. Write down:

  1. Expected outcome: What observable result would show that the task was completed?
  2. Evidence from the run: Which tool calls, inputs, or intermediate results matter?
  3. Valid alternatives: Could the agent succeed through more than one acceptable sequence of actions?
  4. Failure conditions: What would count as a failure even if the final response sounded confident?
  5. Repeatability: Which examples will you run again after changing the prompt, model, or tools?

Keep the test cases and expected outcomes together. Re-run them after changes, and review individual traces when a score does not explain what happened.

Back to top ↑

Research basis

This post is an independent study reference based on publicly available engineering material. It is not an official guide or endorsement from the cited organizations.

AIYING — Accomplishing with AI
AI Engineering Principles & Practice · 002

AI Engineering Principle 001: Start Simple, Add Complexity with Evidence

AI Engineering Principles & Practice · Post 001

Start Simple. Add Complexity with Evidence.

A practical study reference for students, freshers, and teams learning to build useful AI systems.


The principle

A capable AI system does not have to be a complicated one. Begin with the simplest design that could meet the user’s need. Add steps, tools, retrieval, or agent behavior only when you can identify a problem they solve and check whether the change improves the result.

In its engineering guidance on AI agents, Anthropic recommends starting with the simplest solution possible and increasing complexity when needed. The article also describes tradeoffs such as cost and latency when using agentic systems. Read Anthropic’s article.

Worked example: a course handbook assistant

Suppose you are building an assistant that answers questions about a course handbook.

  1. Start with one model call and the relevant handbook text.
  2. Try a small set of realistic questions, including questions the handbook cannot answer.
  3. Record where the answers are incomplete, unsupported, or incorrect.
  4. If the system cannot reliably find the relevant passages, test retrieval.
  5. Consider additional tools or steps only if the test results show a need for them.

The goal is not to keep the system small at any cost. The goal is to make each added component earn its place by addressing an observed failure or requirement.

Independent study exercise

Choose an AI task you might build for a class project, portfolio, or team. Write down:

  1. User outcome: What should the person be able to do or receive?
  2. Smallest first design: What is the simplest system you could try?
  3. Test examples: What inputs would show whether it works?
  4. Failure condition: What result would justify adding another component?
  5. Measure: How will you compare the system before and after the change?

Keep your examples and run them again whenever you change the prompt, model, tools, or workflow. Anthropic’s evaluation guidance describes evaluations as a way to make system behavior and changes more visible during development. Read the evaluation guide.

Study takeaway: Add complexity to solve an observed problem, then measure whether the change helped.

Research basis

This post is an independent learning reference based on publicly available engineering material. It is not an official guide or endorsement from the cited organizations.

AIYING — Accomplishing with AI
AI Engineering Principles & Practice · 001

Sunday, October 4, 2026

The Minimalist Fine-Tuning: Fine-Tuning Explained in 100 Words

The Minimalist Fine-Tuning — Fine-Tuning Explained in 100 Words by Ravindra Dastikop

THE MINIMALIST FINE-TUNING

Fine-Tuning Explained in 100 Words

Ravindra Dastikop

Understand less. Accomplish more.


Why This Book?

Fine-Tuning can sound complicated.

Models.
Datasets.
Examples.
Parameters.
Training.
Supervision.
Objectives.
Validation.
Overfitting.
Evaluation.

But understanding Fine-Tuning does not have to begin with complexity.

This book strips Fine-Tuning down to what matters.

10 ideas.
10 words each.
100 words.
Enough to begin.


How to Read This Book

Read one idea.
Stop.
Think about it.
Try it with AI.
Then move to the next.

The purpose is not to know everything about Fine-Tuning.

The purpose is to understand enough to accomplish something with Fine-Tuning.


01 — FINE-TUNING

Fine-tuning further trains pretrained models for specific tasks or behaviors.

A pretrained model has already learned broad patterns from large amounts of data.

Fine-tuning continues training from that starting point.

Instead of building the model from scratch, we expose the pretrained model to additional task-relevant examples.

Its parameters are then adjusted through further training.

The objective might be to improve:

Task performance.
Output format.
Domain behavior.
Instruction following.
Or another desired capability.

The central idea is:

PRETRAINED MODEL → ADDITIONAL TRAINING → SPECIALIZED MODEL

Fine-tuning adapts an existing model rather than beginning again.


02 — PRETRAINING

Pretraining creates general model capabilities before specialized fine-tuning begins afterward.

Fine-tuning needs something to fine-tune.

That starting point is usually a pretrained model.

Pretraining exposes a model to broad datasets and learning objectives.

Through this process, the model develops general capabilities and learned representations.

Fine-tuning then builds upon that foundation.

This matters because training a large model from scratch can require enormous amounts of data and computation.

Fine-tuning reuses what the model has already learned.

PRETRAINING → GENERAL MODEL → FINE-TUNING → SPECIALIZED MODEL

Pretraining provides the foundation.

Fine-tuning adapts that foundation toward a more specific purpose.


03 — DATASET

Datasets provide examples representing behaviors the fine-tuned model should learn.

Fine-tuning depends heavily on training data.

Suppose you want a model to answer customer-support questions in a particular style.

Your dataset might contain examples of:

User questions.
Desired responses.
Correct formats.
Domain terminology.
Appropriate behaviors.

The model learns from patterns represented in those examples.

This makes dataset quality extremely important.

Poor examples can teach poor behavior.

Inconsistent examples can create inconsistent behavior.

Relevant, representative, carefully prepared examples make the learning objective clearer.

EXAMPLES → DATASET → FINE-TUNING

Fine-tuning quality begins with data quality.


04 — EXAMPLE

Examples demonstrate desired inputs and outputs for model adaptation clearly.

A fine-tuning dataset is built from examples.

For supervised fine-tuning, an example typically shows the model what desirable behavior looks like for a given input or conversational context.

Conceptually:

INPUT → DESIRED OUTPUT

For example:

Customer question → Appropriate support answer.
Document → Desired classification.
Instruction → Correctly formatted response.
Conversation → Preferred assistant behavior.

One example teaches very little by itself.

Many well-designed examples reveal recurring patterns.

The model's parameters can then be adjusted toward producing those patterns more reliably.

EXAMPLES → PATTERNS → LEARNING

Examples turn desired behavior into training evidence.


05 — PARAMETERS

Parameters change during fine-tuning to better represent desired behavioral patterns.

A pretrained neural network contains learned parameters.

These parameters influence how inputs are transformed into outputs.

Fine-tuning changes some or all of them, depending on the method used.

Training examples are processed.

A loss is calculated.

Gradients indicate how trainable parameters should change.

An optimizer applies updates.

Repeated updates gradually adapt the model toward the fine-tuning objective.

Conceptually:

EXAMPLES → LOSS → GRADIENTS → PARAMETER UPDATES

Not every fine-tuning method needs to update every original model parameter.

Parameter-efficient approaches can adapt models by training only a relatively small set of parameters.


06 — SUPERVISION

Supervision supplies target responses that guide learning toward desired behavior.

In supervised fine-tuning, training data provides examples of desired outputs.

The model produces predictions.

Those predictions are compared against target responses.

Training then adjusts the model to reduce the relevant loss.

This gives the model a learning signal.

The supervision effectively says:

For inputs like this, outputs should look more like this.

Supervised fine-tuning is widely used to adapt pretrained language models to instructions, tasks, formats, and desired response patterns.

INPUT + TARGET → TRAINING → ADAPTED BEHAVIOR

Supervision converts examples into direction for learning.


07 — OBJECTIVE

Objectives define what fine-tuning optimization attempts to improve during training.

Training needs something to optimize.

That is the role of the objective.

The objective determines what the learning process rewards or penalizes mathematically.

For supervised language-model fine-tuning, this commonly involves minimizing a loss associated with predicting desired target tokens.

Other post-training methods may use different objectives.

The important distinction is:

The dataset provides examples.

The objective tells optimization what counts as improvement.

DATA + OBJECTIVE → OPTIMIZATION

Without a clearly aligned objective, training may optimize something different from what users actually need.


08 — VALIDATION

Validation checks model performance during development using separate held-out examples.

Training performance alone does not tell us whether fine-tuning is working well.

A model can become increasingly good at reproducing patterns in its training data while becoming less useful on unseen examples.

Validation provides an additional checkpoint.

A separate validation set can help measure performance during model development.

This can reveal:

Overfitting.
Poor generalization.
Weak examples.
Training problems.
Potential model-selection decisions.

TRAIN → VALIDATE → ADJUST

Validation helps us observe whether learning extends beyond the examples used for parameter updates.


09 — OVERFITTING

Overfitting occurs when adaptation fits training examples but generalizes poorly.

Fine-tuning can go too far.

Suppose a model performs extremely well on its fine-tuning examples.

That sounds good.

But then it performs poorly on relevant unseen examples.

The model has not learned sufficiently general patterns for the intended task.

It has fit the training data too specifically.

This is overfitting.

Factors such as dataset size and quality, training duration, model capacity, regularization, and optimization choices can influence it.

The goal is not:

MEMORIZE TRAINING DATA

The goal is:

LEARN USEFUL PATTERNS → GENERALIZE


10 — EVALUATION

Evaluation determines whether fine-tuning actually improves intended model performance reliably.

A completed fine-tuning run is not automatically a successful one.

The resulting model must be evaluated.

Does it perform better on the intended task?

Does it follow the desired format?

Does it generalize to representative unseen examples?

Has another important behavior degraded?

Does it outperform the original model where it matters?

Evaluation should compare evidence rather than impressions.

A useful pattern is:

BASELINE MODEL → EVALUATION

versus

FINE-TUNED MODEL → EVALUATION

Then compare.

Fine-tuning creates a candidate model.

Evaluation determines whether the adaptation created useful improvement.


The Entire Book in 100 Words

FINE-TUNING
Fine-tuning further trains pretrained models for specific tasks or behaviors.

PRETRAINING
Pretraining creates general model capabilities before specialized fine-tuning begins afterward.

DATASET
Datasets provide examples representing behaviors the fine-tuned model should learn.

EXAMPLE
Examples demonstrate desired inputs and outputs for model adaptation clearly.

PARAMETERS
Parameters change during fine-tuning to better represent desired behavioral patterns.

SUPERVISION
Supervision supplies target responses that guide learning toward desired behavior.

OBJECTIVE
Objectives define what fine-tuning optimization attempts to improve during training.

VALIDATION
Validation checks model performance during development using separate held-out examples.

OVERFITTING
Overfitting occurs when adaptation fits training examples but generalizes poorly.

EVALUATION
Evaluation determines whether fine-tuning actually improves intended model performance reliably.


The Minimalist Fine-Tuning

You do not need to understand everything about Fine-Tuning before you begin.

Remember ten things:

Fine-Tuning.
Pretraining.
Dataset.
Example.
Parameters.
Supervision.
Objective.
Validation.
Overfitting.
Evaluation.

Everything else can come later.

Start with a pretrained model.
Define the behavior you want.
Prepare representative examples.
Provide desired outputs.
Train appropriate parameters.
Supply supervision.
Optimize the objective.
Validate during development.
Watch for overfitting.
Evaluate against the original model.

Then determine whether fine-tuning actually created value.


One Final Question

The next time you hear “fine-tuning,” don't begin with:

“How do we train the model?”

Begin with:

“What behavior do we want the existing model to learn better?”

Then think Fine-Tuning.


Accomplish with AI

Powered by Blogger.

Featured post

AI Engineering Hands-On Lab #001 — Build an AI Answer Reliability Test Bench Without Code

AIYING | Daily 24 — Post 009 AI Engineering Hands-On Lab #001 Build an AI Answer Reliability Test Bench — Without Writing Code Lea...

Search This Blog

List of blogs

Search This Blog

About

Translate

Instant Stories

Read in Your Language

Test

share this

ShareThis

Popular Posts