如何追蹤價格資料在整個 AI 工作流程中的變化

A supplier's attachment contains the right price. The extraction returns the right number. The quote still ends up wrong because a later step assigns that number to a different pack size. Looking only at the model response would send the investigation in the wrong direction. The useful question is where the meaning changed.

Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked technical sources. The opening scenario and instrumentation examples are hypothetical, not reports of a client incident.

My TMC Price Intelligence case study describes a delivered 2023–2025 engagement connecting supplier emails and attachments to structured pricing records, a central repository, reviewable reports, and quote and invoice workflows. Product type, size, price, region, and supplier were part of the extracted information. AI interpretation was one step in that broader operational process.

That kind of pipeline needs an explanation that spans the handoffs. If a downstream record looks wrong, the team should be able to investigate extraction separately from normalization, storage, review, and output generation.

Model tracing is a useful starting point

Anthropic's October 14, 2026 release notes announced OpenTelemetry export in beta for Messages API requests and Claude Managed Agents sessions. Its SDK and API can provide spans for observability systems. This is a current development in model-level tracing, not a feature of my earlier TMC engagement.

The OpenTelemetry trace documentation explains how related spans represent operations within a trace. For an extraction workflow, the model request can become one operation within an application-level investigation. It does not automatically explain the business transformations that happen before or after that request.

For a comparable pipeline today, I would start by instrumenting the boundaries where information changes shape. An attachment is decoded. Text becomes extracted fields. A description maps to a product record. A reviewed record becomes a quote line. Each boundary can succeed technically while still producing a result that needs scrutiny.

Connect execution to the record being investigated

I would give an incoming document a stable internal identifier and each processing attempt a separate identifier. Keep the resulting pricing record linked to the relevant source and attempt. A trace identifier can help find the execution, while the application retains the durable relationship between the source and its derived records.

The distinction matters when work is retried or revisited. A later import may process the same attachment with a revised parser or normalization rule. The operator needs to know which attempt produced the record now under discussion, rather than finding a successful run that happened to involve the same supplier.

For each transformation, record the versions that affect interpretation: parser configuration, extraction schema, model choice where applicable, and normalization rules. These are suggested design details, not claims about fields implemented in the historical system. Their purpose is to make a change in behavior explainable.

Do not use a trace viewer as the only place where business provenance lives. Telemetry can be sampled, expire, or arrive incompletely. The application still needs the source relationships and review history required to explain its operational records.

Separate a completed operation from an accepted value

A parser completing without an exception says something about execution. It does not prove the extracted price belongs to the intended product. A normalization function returning a value does not prove two supplier descriptions are comparable.

For the hypothetical pack-size mismatch, I would inspect the extracted size, the selected product mapping, and the rule that joined the price to the quote line. If the extraction was correct, changing the extraction prompt could add cost while leaving the actual defect untouched.

A useful diagnostic view should show where a record was held for review and why. Missing unit information, ambiguous product mapping, and a failed downstream write deserve distinguishable outcomes. Label a validation result according to the rule it checked. “Required fields present” is more informative than a broad claim that the record is correct.

This makes operational review more focused. The person investigating can inspect the stage that lost context instead of rereading every attachment or asking a model to reconsider the entire workflow.

Choose what telemetry is allowed to contain

Anthropic's tracing guide distinguishes metadata-only tracing from full-content tracing. Metadata is the default; full content can include model prompts and responses. The guide also explains that the observability destination stores exported material under its own access and retention settings.

For a supplier-document workflow, I would begin with deliberately selected metadata and protected source references. Full messages or attachments can carry commercial information that an operator does not need in a general tracing dashboard. Even identifiers and descriptive attributes need a deliberate policy; calling a field metadata does not make its contents harmless.

There is a tradeoff. Less captured content can make a difficult extraction failure harder to reproduce. Address that through controlled access to an appropriate source or a sanitized reproducer, with retention and permissions that fit the organization. A useful trace should help locate the evidence without casually duplicating the entire inbox.

Measure the outcome after the handoffs

Once stages can be distinguished, timing becomes more useful too. A slow end-to-end process may be waiting on review or a downstream service rather than inference. Model latency alone will not tell the team where to invest effort.

I would measure processing time alongside how often records reach their intended operational state, how often they need correction, and which stages produce unresolved exceptions. Define those measures against the workflow's actual decisions. Instrumentation makes the process easier to inspect; it does not by itself establish accuracy or savings.

As model tracing becomes easier to adopt, the opportunity is to connect it to the rest of the application. Follow the source, the transformation, and the resulting record. That gives a team a practical way to improve the stage that needs work instead of treating every bad output as a prompting problem.