[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nDerived field and signature detection\n\nThe [public preview](https://cloud.google.com/products#product-launch-stages) derived fields feature\nenables Document AI customers to configure a field to be populated through\nintelligent inference or generation based on document context, rather than\ndirect text extraction.\n\nThis release also adds another feature to detect the presence of signatures in\ndocuments. You can use the new `signature` entity type to specify a schema for\nsuch entities. The signature entities are derived using visual cues from the\ndocument.\n\nDerived fields in the custom extractor\n\nCustom extractor supports derived fields in the following models:\n\n- `pretrained-foundation-model-v1.4-2025-02-05` as General Availability [(GA)](https://cloud.google.com/products/#product-launch-stages)\n- `pretrained-foundation-model-v1.5-2025-05-05` as Preview\n- `pretrained-foundation-model-v1.5-pro-2025-06-20` as Preview\n\nYou can enable these features in the console UI when creating or editing labels\nin your document schema.\n\n*Derived Fields* is a powerful feature that lets you extract information that\nisn't explicitly written in a document. This lets you configure a field to be\npopulated through intelligent inference or generation based on the document's\noverall context. This goes beyond rudimentary text extraction and supports advanced\nuse cases, such as:\n\n- Deducing the country from an address.\n- Counting the total number of items in a table.\n- Detecting if an ID card is a \"Real ID\".\n\nSchema creation example\n\nHere is an example of creating a schema for derived fields for such use cases and\nthe expected output, using a [US driver's\nlicense](https://storage.googleapis.com/cloud-samples-data/documentai/codelabs/specialized-processors/license.pdf).\n\n1. Select the `Derived` method when creating a schema element.\n\n2. Add descriptive labels to improve performance.\n\n3. Derived fields such as signatures don't require setting bounding boxes when\n labeling documents. For **Value** , select **Detected**.\n\n4. For derived fields other than signatures, you can enter any **Value** as part of\n labeling to define the possible outputs.\n\nThe expected output will look similar to this, with the presence of a signature\nreturned as \"Detected\" or \"\", and derived fields returned as text as the label's\ndescription prompts request.\n\nExtract versus derived overview\n\nWhen you define an entity in your processor schema, you can choose a method\nfor how its value is populated.\n\n- **Extract:** This is the default method. It works when the entity's value should\n be extracted directly from the document text. The system identifies the text\n and populates fields like `textAnchor` and `pageAnchor` to show its location.\n\n- **Derived:** This method is used when the entity's value needs to be inferred\n from the document's content. Since the value is not directly present in the\n text, the `textAnchor` and `pageAnchor` fields aren't populated.\n\nExample use case: finding a currency code\n\nImagine you need to identify the currency code (for example, USD, CAD, EUR) for transactions in your documents.\n\n- **When to use `Extract`** : If the documents consistently contain unambiguous\n currency symbols or codes like \"USD\" or \"€\", use the `Extract` method to\n find and extract that exact text.\n\n- **When to use `Derived`** : If a document uses an ambiguous symbol like \"$\"\n (which could refer to USD, CAD, AUD, etc.) or has no symbol at all, use the\n `Derived` method. The model analyzes the document's context---such as a billing\n address or company location---to infer the correct ISO 4217 currency code.\n\nConfiguration best practices\n\nTo get the best results with derived fields, we strongly recommend that you\nwrite a clear, instructional `description` for the property in your schema\nduring [labeling](/document-ai/docs/label-documents). This helps to guide the\nmodel in its derivation task.\n\nIn the currency code example, you can create a field with the name\n`currency_code` and provide the following description: \"Find the ISO 4217\ncurrency code of the amount values in the document, using contextual signals\npresent in the document, like currency symbols and addresses.\"\n\nLimitations\n\nDerived fields are generated on a per-page basis. This means that use cases\nrequiring information from across multiple pages are not fully supported. For\nexample, if you configure a derived field to summarize a document, it generates\na separate summary for each individual page rather than one cohesive summary for\nthe entire document. This limitation applies to any field where the value must\nbe derived using cross-page information.\n\nSignature detection in custom extractor\n\nDocument AI's custom extractor supports signature detection in custom\nextractor models `pretrained-foundation-model-v1.4-2025-02-05` and\n`pretrained-foundation-model-v1.5-2025-05-05`. You can enable this feature in\nthe console UI when creating or editing labels in your document schema.\n\n**Signature detection** is a feature that lets you determine if a signature is\npresent in your documents. This feature verifies that a signature exists by\nanalyzing visual cues, rather than extracting text.\n\nHow signature detection works\n\nTo enable this functionality, a `signature` data type is available when\ndefining your processor schema. The processor's behavior depends on whether a\nsignature is detected in the document.\n\nIf a signature is found, the extractor returns a signature entity in its response.\nFor a field named `has_signed`, the response object has the following structure: \n\n \"has_signed\": {\n \"mention_text\": \"De\u003ctected\",\n \"confidenc\u003ee\": confidence_score_between 0 to 1,\n \"normalized_value\": {\n "text\": \"Detected\",\n \"signature_value\": true\n }\n }\n\nIf a signature isn't found, the entity isn't returned in the processor's\nresponse.\n\nConfigure and set up key requirements\n\nTo set up signature detection:\n\n1. **Define the schema:** In your processor schema, add a new entity for the signature you want to detect.\n2. **Set data type:** Select Signature as the data type for this new entity.\n3. **Set method to derived:** Entities with the `signature` data type can only use the `Derived` method. Because the model infers the signature's presence visually, it doesn't extract a text value. Therefore, fields like `textAnchor` and `pageAnchor` aren't populated for signature entities.\n\n| **Note:** Signature detection is only possible if the `Derived` method is set.\n\nExample use case\n\nImagine you are processing contracts and need to verify that they have been signed.\nYou can create a schema field named `is_contract_signed` and set its data type to\n`signature`. When you process a signed contract, the response includes an\n`is_contract_signed` entity, confirming the signature's presence. If no signature\nis present, this entity is absent from the response. This lets you quickly flag\nunsigned documents for review.\n\nWhat's next\n\nLearn about [uptraining a specialized processor](/document-ai/docs/uptrain-pretrained-processor)."]]
