HITL 라벨러 워크벤치는 문서 엔티티를 추출된 라벨에 매핑하는 WYSIWYG (What You See Is What You Get) 인터페이스를 제공하므로 라벨러가 쉽게 비교하고 수정할 수 있습니다. 인간 라벨러에게 어떤 라벨을 찾아 추가해야 하는지, Document AI 모델이나 HITL의 검증 필터에서 누락된 경우를 안내하는 안내 문서가 필요합니다. 여기에는 다음이 포함됩니다.
검토할 라벨입니다.
필수 또는 선택 입력란이 있는지 여부입니다.
라벨 수정 (예: 미국이 지정되지 않은 미국 주소에 'USA' 추가)
올바른 거부 필드가 있는 문서를 거부합니다(예: $10,000 초과 인보이스 거부).
스키마 라벨에 매핑되는 문서의 특수 라벨 이름으로, 라벨러가 이를 추가할 수 있습니다(예: '고객 번호' = '계정 번호').
이는 HITL 작업 구성에서 필터로 설정할 수 있습니다.
효과적인 안내 설계
효과적인 안내는 양질의 수동 라벨링 결과를 보장하는 데 가장 중요한 요소입니다. 효과적인 안내는 수동 라벨러에게 원하는 작업 방식을 알려주는 안내입니다. 다음은 효과적인 안내 작성에 관한 몇 가지 가이드라인입니다.
수동 라벨러는 사용자의 도메인 관련 지식을 보유하고 있지 않을 수 있습니다. 라벨러에게 전달하는 지침은 사용 사례를 잘 모르는 사람도 쉽게 이해할 수 있어야 합니다.
안내가 너무 길면 안 됩니다. 라벨러가 20분 안에 살펴보고 이해할 수 있을 정도의 길이가 가장 좋습니다.
안내는 태스크의 개념과 데이터에 라벨을 지정하는 방법을 모두 설명해야 합니다.
안내에 대응하는 라벨 세트가 포함되어 있다면 안내는 해당 세트에 있는 모든 라벨에 적용될 수 있어야 합니다. 안내에 있는 라벨 이름은 라벨 세트에 있는 이름과 일치해야 합니다.
일반적으로 이 과정을 몇 번 거쳐야 효과적인 안내가 완성됩니다. 먼저 작은 데이터 세트에 라벨을 지정한 다음 결과를 바탕으로 안내를 수정하는 방법을 권장합니다.
효과적인 안내에는 다음 항목이 포함되어야 합니다.
라벨 목록 및 설명: 사용된 라벨을 모두 나열하고 각 라벨의 의미를 설명합니다.
예시: 각 라벨에 긍정 예시를 3개 이상, 부정 예시를 1개 이상 제시합니다. 이러한 예는 다양한 사례에 적용될 수 있어야 합니다.
특이 사례 적용: 다양한 특이 사례를 최대한 명확하게 설명합니다. 이렇게 하면 라벨러가 라벨을 해석하지 않아도 됩니다. 예를 들어 인물 주위에 경계 상자를 그려야 한다면 조건을 명확하게 설명하는 것이 좋습니다.
사람이 여러 명 있으면 각 사용자별로 상자가 필요한가요?
사람이 가려진 경우 상자가 필요한가요?
이미지에 일부만 보이는 사람에도 상자를 그려야 하나요?
사진이나 그림에 있는 사람에 대해서도 상자를 그려야 하나요?
주석을 추가하는 방법을 설명하세요. 예를 들면 다음과 같습니다.
경계 상자는 꼭 맞아야 하나요, 여유가 있어야 하나요?
텍스트 항목 추출 작업에서 관심 있는 항목의 시작 지점과 종료 지점은 어디인가요?
라벨을 명확하게 설명해야 합니다. 라벨 두 개가 서로 비슷하거나 혼동하기 쉽다면 예시를 제시해 차이를 명확하게 설명하세요.
시각적 예시
시각적 예시는 문서에서 다양한 항목을 어디에서 찾아야 하는지, 스키마에서 추출된 라벨에 어떻게 매핑되는지 라벨러에게 명확하게 설명합니다.
다음과 같이 시각적 예시를 포함하세요.
[[["이해하기 쉬움","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-10(UTC)"],[[["\u003cp\u003eDocument AI Human-in-the-Loop (HITL) is being deprecated and will no longer be available on Google Cloud after January 16, 2025, and new customers are not being allowed, requiring existing users without the option to contact their Google Account team.\u003c/p\u003e\n"],["\u003cp\u003eHuman labelers require a clear instruction document that outlines which labels to review, if there are mandatory fields, business logic for corrections or rejections, and any special label name mappings to schema labels.\u003c/p\u003e\n"],["\u003cp\u003eGood instructions are concise, understandable by those unfamiliar with the domain, and should be reviewable within 20 minutes, including the concept and details of how to label the data.\u003c/p\u003e\n"],["\u003cp\u003eAn effective instructions file must contain a list of labels with descriptions, multiple positive and at least one negative example per label, edge case clarifications, and guidance on how to add annotations.\u003c/p\u003e\n"],["\u003cp\u003eVisual examples should be included in instructions to help clarify where different entities are expected in the document and how they should be mapped to the schema labels.\u003c/p\u003e\n"]]],[],null,["| **Caution** : Document AI Human-in-the-Loop is deprecated and will no longer be available on Google Cloud after January 16, 2025. New customers are not allowlisted. If you want to use (HITL) but don't see the option available, contact your Google Account team. \n|\n| To implement a human review and correction solution that meets your requirements, we recommend working with a Google Cloud certified partner like Devoteam, Searce, or Quantiphi. See [Deprecations](/document-ai/docs/deprecation) for details.\n\n\u003cbr /\u003e\n\n\n| **Note** : This product is subject to the [Data Processing and Security Terms](/terms/data-processing-terms).\n\n\u003cbr /\u003e\n\nWhile the HITL Labeler Workbench provides a What You See Is What\nYou Get (WYSIWYG) interface that maps document entities to the extracted labels,\nwhich makes it easy for the labeler to compare and correct. An instructions\ndocument is needed to instruct the human labelers of which labels to look for\nand add, and in case it's missed by the Document AI model or validation\nfilters of HITL. This includes:\n\n- Which labels to review.\n- Whether any fields are mandatory or optional.\n- Any business logic to\n - Correct labels (such as add \"USA\" for United States addresses that don't specify USA).\n - Reject documents with the correct rejection field - such as reject invoices \\\u003e$10,000.\n- Special label names in the document that map to schema labels, so labeler can add these - such as \"Client #\" = \"Account #\".\n- These can be set up as Filters in the HITL task configuration.\n\n\u003cbr /\u003e\n\nDesign good instruction\n\nGood instructions are the most important factor in getting good human labeling\nresults. Good instructions are those that let human labelers know what you want\nthem to do. Here are some guidelines for creating good instructions:\n\n- The human labelers might not have your domain knowledge. The distinctions you ask labelers to make must be easy to understand for someone unfamiliar with your use case.\n- Avoid making the instructions too long. It is best if a labeler can review and understand them within 20 minutes.\n- Instructions must describe the concept of the task as well as details about how to label the data.\n- If your instructions have a corresponding label set, they must cover all labels in that set. The label name in the instructions must match the name in the label set.\n- It often takes several iterations to create good instructions. We recommend having a small dataset labeled first, then adjusting your instructions based on what you see in the results you receive.\n\n\u003cbr /\u003e\n\nA good instructions file must include the following sections:\n\n- Label list and description: list all of the labels that are used and describe the meaning of each label.\n- Examples: For each label, give at least three positive examples and one negative example. These examples must cover different cases.\n- Cover edge cases. Clarify as many edge cases as you can, This reduces the need for the labeler to interpret the label. For example, if you need to draw a bounding box for a person, it is better to clarify:\n - If there are multiple people, do you need a box for each person?\n - If a person is occluded, do you need a box??\n - Do you need a box for a person who is partially shown in the image?\n - Do you need a box for a person in a picture or painting?\n- Describe how to add annotations. For example:\n - For a bounding box, do you need a tight box or a loose box?\n - For text entity extraction, where should the interested entity start and end?\n- Clarification on labels. If two labels are similar or easy to confuse, give examples to clarify the differences.\n\n\u003cbr /\u003e\n\nVisual Examples\n\nThe visual example provides clarification to the labelers where to expect\ndifferent entities in the document and how they map to the extracted labels in\nthe schema.\nInclude visual examples in your instructions like the following:"]]