診断の土台としてのログ

The central idea of this chapter is to record the entire process before improving an image. The presenters explain that the system logs image understanding, routing, editing, quality assurance (QA), post-processing, and the publication decision in a mostly flat JSON format. This makes it possible to investigate both one failed case and patterns shared by many cases.

Why logging must come first

To improve a production system, the team must be able to check later where and why a result occurred. Saving only the final image does not show what the router saw, why it chose enhance or skip, what the editing agent generated, or why QA accepted the result. The system therefore keeps the whole case flow as one record.

What an end-to-end trace contains

An end-to-end trace is not only the final output. It should make at least these three kinds of evidence traceable:

• What was received: inputs to each agent, such as the image, description, and metadata.
• What was decided: image understanding, quality judgments, the enhance-or-skip route, and QA decisions.
• What was produced: the description, edited image, post-processing result, and publication decision.

With this distinction, a team does not have to blame only the editing agent when the result is bad. It can follow the same case to determine whether the router chose the wrong branch, the edit changed too much, or QA missed the problem.

An inspectable flat JSON record

The presenters emphasize representing the logs in a mostly flat JSON format. Here, flat means avoiding a structure in which information is scattered across many places and the reader must follow many links to understand it. The related inputs, decisions, and outputs for one case should be visible from the same record as far as possible.

This format is not only for technical teams. Engineers can investigate a specific failure. Product, design, operations, and other teams can inspect many cases together and ask at which stage problems are increasing. The same logs therefore support both case-level diagnosis and overall optimization.

Supplement: an explanatory example

This is an author-created example to show the idea, not the exact schema shown in the presentation. The actual field names and JSON structure were not disclosed. The important point is that the related evidence from input through publication can be inspected together, rather than looking only at route, for example.

One record supplies evidence for diagnosing an individual case. Aggregating the same fields across many records reveals overall patterns. For example, it provides a basis for checking whether images from a particular region or dish are skipped unusually often. However, this part of the presentation does not specify the exact aggregate fields or JSON fields.

Figure: A presentation slide showing a flat, end-to-end JSON log for an image-enhancement case.

This slide shows the idea of combining the case input, image understanding, routing, generation and post-processing, and QA outcome in one flat, JSON-like record. It makes the presenters' logging-first explanation concrete: evidence from each stage is connected in one place. The relevant part of the presentation is around 6:29 on YouTube.

Logging, observability, and evaluation metrics

These three are not the same. Logs are the evidence itself. Observability is the mechanism for understanding system state from that evidence. Metrics are results summarized to make groups of cases easier to compare. Metrics help later optimization, but the original logs are needed to calculate them and investigate their causes.

Leave unspecified things unspecified

The claim that logging is important is clear, but the presentation does not show the actual JSON fields, storage method, or aggregation system. There is also an unclear phrase near the transition in the transcript. This chapter does not guess a technical meaning for that phrase. It stays with the supported point: a flat log enables teams to diagnose cases.

Logs make the closed loop possible

With logs, the team can find failures, isolate their causes, and optimize the next configuration or agent. Without evidence, it cannot decide what to fix. Logging is therefore not merely a monitoring record. It is the starting point for the later evaluation, diagnosis, and self-learning loops.