議論： JSON Schema、検証、回数制限付き再試行による文書からの構造化抽出

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

Step 4's retry loop is designed for shape errors and misbehaves for the semantic checks step 3 adds. With constrained decoding enabled (step 2), schema failures cannot occur, so the only thing that reaches the retry is a semantic failure: 'line items do not sum to the total', 'date outside range', 'ID not in master data'. Feeding that message back together with the offending value invites the model to *satisfy the check* rather than re-read the document: adjust one line item until the sum matches, move the date into range, pick a nearby ID that exists. A record that passes on the second attempt after such a retry is worse than one in the review queue, because it is wrong and now looks verified. The condition is the type of failure: for genuinely structural problems (a missing required field the schema could not express, an enum mismatch) error feedback is right; for consistency failures the retry should re-present the document and the rule *without the previous answer*, or, for critical fields, skip the retry and route to review directly, and the per-field accuracy table in step 7 should be split by 'first attempt' and 'after retry' so that manufactured consistency shows up as a divergence between them.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

Two constraints from the cited provider documentation that affect steps 2 and 5. Schema-constrained output does not accept arbitrary JSON Schema: for strict tool inputs the schema must set `additionalProperties: false` and declare `required`, which is the shape the prerequisites already ask for; other providers' strict modes go further and require every property to be listed as required, with optional fields expressed as nullable types, so a schema written that way ports to all of them. Second, the provider-side citations feature, which would be the natural implementation of step 5's provenance (it returns `cited_text` with character, page or content-block locations into the supplied documents), is documented as incompatible with structured output: enabling citations together with an output format returns a 400. So a pipeline must choose per call between constrained shape and API-verified provenance; the article's design, in which the quote is a field in the schema and the string match happens in code, is the version that works with constrained decoding, and citations belong in a separate, unconstrained pass if they are wanted.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-21

翻訳がないため、原文を表示しています。 原文

One vendor's cookbook for pre-parsed value extraction inverts step 1 usefully: regular expressions find every candidate e-mail address, phone number and amount in the document first, and a decision model only selects which candidate is the requested one, so the value that reaches the record is verbatim from the text and code normalises it. That splits extraction into a deterministic part (finding spans) and a judgment (choosing among them), and the judgment step returns probabilities that can gate a human check.