エージェントを継続的に改善するデータフライホイール

This chapter examines a data flywheel for continuously improving agents, starting with evals and observability. Instead of stopping after running an agent, the team collects execution records, learns from them, and applies the learning to the next experiment.

What the flywheel means

A flywheel here means a cycle of improvement that is repeated many times. The speaker presents a recipe: run an initial agent, collect and organize the results as data, and then experiment. The changes learned from the experiment are fed back into the agent.

1. Build an agent and run a task.
2. Collect execution traces. A trace is a record of what happened during one run, including interactions with the model and tool executions.
3. Select and organize traces so they can be used in experiments. The talk does not specify a detailed labeling procedure for this organization.
4. Try changes and evaluate the results.
5. Apply what was learned to the model, the context, or the harness.

Figure: This slide shows the continuous-improvement process of running an initial agent, collecting and curating traces, and experimenting with that data.

The slide presents the recipe described by the speaker as a four-stage flow. It starts by running an initial agent, moves through trace collection and curation, and reaches experiments using that data. The diagram supports the overall process, but it does not show the detailed curation method or experiment results.

Adding feedback to traces

Collecting traces alone does not determine what to improve. Feedback is needed to show which runs were good and which had problems. The speaker divides the main sources of feedback into two groups.

• Feedback from the real environment or from users
• Synthetic feedback produced by judging traces with an online evaluator

Feedback from users

Users do not always click an explicit thumbs-up or thumbs-down button. Even so, carefully designing how results are presented can produce useful information from user reactions. This means that user-interface design (UX) can become a mechanism for eliciting feedback. The talk does not specify a detailed screen example here.

Synthetic feedback from online evaluators

The other approach is to have an online evaluator judge traces. The evaluator is not the agent being evaluated. A different strong model, a different small model, or code examines the trace and returns a judgment. Thus, even when another LLM or agent acts as the judge, the judge and the original agent have different roles.

• Judge every trace with a strong model
• Depending on the test, judge with a fine-tuned small model or a prompted off-the-shelf model
• Judge with code when the decision rules are clear

Using a strong model for every trace may provide high-quality judgments. However, it can cost more and tend to be slower. A small model or code may improve speed and cost. The choice depends on the balance among the judgment quality, speed, and cost required by the test. The speaker does not say that every test should use the same evaluator.

What should be improved?

The place to improve is not limited to one part of the system.

• Improve the harness: Change how tools, procedures, or control are handled.
• Fine-tune the model: Help the model handle the same kind of work better.
• Update the context: Change the information available in the next run through memory.

These are three different intervention paths. For example, if the needed information is missing from the context, the team may first review memory or the harness. If model capability is the problem, it may try changing or fine-tuning the model. However, an eval result alone does not determine the cause. The team examines the trace and decides which change to test next.

Why automation is needed

Doing all of the execution, trace collection and curation, evaluation, changes, and reruns by hand is difficult and time-consuming. The speaker uses this sequence to lead into the next Engine demo, which is presented as a direction for automating the process. The flywheel does not guarantee that every change improves performance. It is a way to measure, adjust, and check the result again.

Note: The talk also mentions a team member's slide and an experiment using Harvey. However, the dataset, evaluation results, and detailed evaluator prompts used there are not included in these materials. Therefore, this chapter does not add specific numbers or names of particular models.