[]The Amazon Machine Learning Solutions Lab (MLSL) recently created a tool for annotating text with named-entity recognition (NER) and relationship labels using Amazon SageMaker Ground Truth. Annotators use this tool to label text with named entities and link their relationships, thereby building a dataset for training state-of-the-art natural language processing (NLP) machine learning (ML) models. Most importantly, this is now publicly available to all AWS customers.
[]Booking.com is one of the world’s leading online travel platforms. Understanding what customers are saying about the company’s 28 million+ property listings on the platform is essential for maintaining a top-notch customer experience. Previously, Booking.com could only utilize traditional sentiment analysis to interpret customer-generated reviews at scale. Looking to upgrade the specificity of these interpretations, Booking.com recently turned to the MLSL for help with building a custom annotated dataset for training an aspect-based sentiment analysis model.
[]Traditional sentiment analysis is the process of classifying a piece of text as positive, negative, or neutral as a singular sentiment. This works to broadly understand if users are satisfied or unsatisfied with a particular experience. For example, with traditional sentiment analysis, the following text may be classified as “neutral”:
[]Our stay at the hotel was nice. The staff was friendly and the rooms were clean, but our beds were quite uncomfortable.
[]Aspect-based sentiment analysis offers a more nuanced understanding of content. In the case of Booking.com, rather than taking a customer review as a whole and classifying it categorically, it can take sentiment from within a review and assign it to specific aspects. For example, customer reviews of a given hotel might praise the immaculate pool and fitness area, but give critical feedback on the restaurant and lounge.
[]The statement which would have been classified as “neutral” by traditional sentiment analysis will, with aspect-based sentiment analysis, become:
[]Our stay at the hotel was nice. The staff was friendly and the rooms were clean, but our beds were quite uncomfortable.
[]Booking.com sought to build a custom aspect-based sentiment analysis model that would tell them which specific parts of the guest experience (from a list of 50+ aspects) were positive, negative, or neutral.
[]Before Booking.com could build a training dataset for this model, they needed a way to annotate it. MLSL’s annotation tool provided the much-needed customized solution. Human review was performed on a large collection of hotel reviews. Then, annotators completed named-entity annotation on sentiment and guest-experience text spans and phrases before linking appropriate spans together.
[]The new aspect-based model lets Booking.com personalize both accommodations and reviews to its customers. Highlighting the positive and negative aspects of each accommodation enables the customers to choose their perfect match. In addition, different customers care about different aspects of the accommodation, and the new model opens up the opportunity to show the most relevant reviews to each one.
[]Although Ground Truth provides a built-in NER text annotation capability, it doesn’t provide the ability to link entities together. With this in mind, Booking.com and MLSL worked out the following high-level requirements for a new named entity recognition text labeling tool that:
[]Consider the following document:
[]We loved the location of this hotel! The rooftop lounge gave us the perfect view of space needle. It is also a short drive away from pike place market and the waterfront.
Food was only available via room service, which was a little disappointing but makes sense in this post-pandemic world.
Overall, a reasonably priced experience.
[]Loading this document into the new NER annotation presents a worker with the following interface:
[]Worker presented with an unannotated document
[]In this case, the worker’s job is to:
[]Worker performing annotations
[]Annotation speed was an important consideration of the tool. Using a sequence of intuitive keyboard shortcuts and mouse gestures, annotators can drive the interface and:
[]Additionally, there is support for overlapping labels. For example, Seattle Space Needle: in this phrase, Seattle is annotated both as a location by itself and as a part of the attraction name.
[]The completed annotation provides a more complete, nuanced analysis of the data:
[]Relationships can be configured in many levels, from entity categories to other entity categories (for example, from “food” to “sentiment”), or between individual entity types. Relationships are directed, so annotators can link an aspect like food to a sentiment, but not vice-versa (unless explicitly enabled). When drawing relationships, the annotation tool will automatically deduce the relationship label and direction.
[]In this section, we cover how to customize the NER annotation tool for customer-specific use cases. This includes configuring:
[]We’ll cover the specifics of the input and output document formats, as well as provide some examples of each.
[]The NER annotation tool expects the following JSON formatted input document (Fields with a question mark next to the name are optional).
{ text: string; tokenRows?: string[][]; documentId?: string; entityLabels?: { name: string; shortName?: string; category?: string; shortCategory?: string; color?: string; }[]; classificationLabels?: string[]; relationshipLabels?: { name: string; allowedRelationships?: { sourceEntityLabelCategories?: string[]; targetEntityLabelCategories?: string[]; sourceEntityLabels?: string[]; targetEntityLabels?: string[]; }[]; }[]; entityAnnotations?: { id: string; start: number; end: number; text: string; label: string; labelCategory?: string; }[]; relationshipAnnotations?: { sourceEntityAnnotationId: string; targetEntityAnnotationId: string; label: string; }[]; classificationAnnotations?: string[]; meta?: { instructions?: string; disableSubmitConfirmation?: boolean; multiClassification: boolean; }; } []In a nutshell, the input format has these characteristics:
Field | Type | Description |
text | string | Required. Input text for annotation. |
tokenRows | string[][] | Optional. Custom tokenization of input text. Array of arrays of strings. Top level array represents each row of text (line breaks), and second level array represents tokens on each row. All characters/runes in the input text must be accounted for in tokenRows, including any white space. |
documentId | string | Optional. Optional value for customers to keep track of document being annotated. |
entityLabels | object[] | Required if classificationLabels is blank. Array of entity labels. |
entityLabels[].name | string | Required. Entity label display name. |
entityLabels[].category | string | Optional. Entity label category name. |
entityLabels[].shortName | string | Optional. Display this text over annotated entities rather than the full name. |
entityLabels[].shortCategory | string | Optional. Display this text in the entity annotation select dropdown instead of the first four letters of the category name. |
entityLabels.color | string | Optional. Hex color code with “#” prefix. If blank, then it will automatically assign a color to the entity label. |
relationshipLabels | object[] | Optional. Array of relationship labels. |
relationshipLabels[].name | string | Required. Relationship label display name. |
relationshipLabels[].allowedRelationships | object[] | Optional. Array of values restricting what types of source and destination entity labels this relationship can be assigned to. Each item in array is “OR’ed” together. |
relationshipLabels[].allowedRelationships[].sourceEntityLabelCategories | string[] | Required to set either sourceEntityLabelCategories or sourceEntityLabels (or both). List of legal source entity label category types for this relationship. |
relationshipLabels[].allowedRelationships[].targetEntityLabelCategories | string[] | Required to set either targetEntityLabelCategories or targetEntityLabels (or both). List of legal target entity label category types for this relationship. |
relationshipLabels[].allowedRelationships[].sourceEntityLabels | string[] | Required to set either sourceEntityLabelCategories or sourceEntityLabels (or both). List of legal source entity label types for this relationship. |
relationshipLabels[].allowedRelationships[].sourceEntityLabels | string[] | Required to set either targetEntityLabelCategories or targetEntityLabels (or both). List of legal target entity label types for this relationship. |
classificationLabels | string[] | Required if entityLabels is blank. List of document level classification labels. |
entityAnnotations | object[] | Optional. Array of entity annotations to pre-annotate input text with. |
entityAnnotations[].id | string | Required. Unique identifier for this entity annotation. Used to reference this entity in relationshipAnnotations. |
entityAnnotations[].start | number | Required. Start rune offset of this entity annotation. |
entityAnnotations[].end | number | Required. End rune offset of this entity annotation. |
entityAnnotations[].text | string | Required. Text content between start and end rune offset. |
entityAnnotations[].label | string | Required. Associated entity label name (from the names in entityLabels). |
entityAnnotations[].labelCategory | string | Optional.Associated entity label category (from the categories in entityLabels). |
relationshipAnnotations | object[] | Optional. Array of relationship annotations. |
relationshipAnnotations[].sourceEntityAnnotationId | string | Required. Source entity annotation ID for this relationship. |
relationshipAnnotations[].targetEntityAnnotationId | string | Required. Target entity annotation ID for this relationship. |
relationshipAnnotations[].label | string | Required. Associated relationship label name. |
classificationAnnotations | string[] | Optional. Array of classifications to pre-annotate the document with. |
meta | object | Optional. Additional configuration parameters. |
meta.instructions | string | Optional. Instructions for the labeling annotator in Markdown format. |
meta.disableSubmitConfirmation | boolean | Optional. Set to true to disable submit confirmation modal. |
meta.multiClassification | boolean | Optional. Set to true to enable multi-label mode for classificationLabels. |
[]Here are a few sample documents to get a better sense of this input format
[]Documents that adhere to this schema are provided to Ground Truth as individual line items in an input manifest.
[]The output format is designed to feedback easily into a new annotation task. Optional fields in the output document are set if they are also set in the input document. The only difference between the input and output formats is the meta object.
{ text: string; tokenRows?: string[][]; documentId?: string; entityLabels?: { name: string; shortName?: string; category?: string; shortCategory?: string; color?: string; }[]; relationshipLabels: { name: string; allowedRelationships?: { sourceEntityLabelCategories?: string[]; targetEntityLabelCategories?: string[]; sourceEntityLabels?: string[]; targetEntityLabels?: string[]; }[]; }[]; classificationLabels?: string[]; entityAnnotations?: { id: string; start: number; end: number; text: string; labelCategory?: string; label: string; }[]; relationshipAnnotations?: { sourceEntityAnnotationId: string; targetEntityAnnotationId: string; label: string; }[]; classificationAnnotations?: string[]; meta: { instructions?: string; disableSubmitConfirmation?: boolean; multiClassification: boolean; runes: string[]; rejected: boolean; rejectedReason: string; } }
Field | Type | Description |
meta.rejected | boolean | Is set to true if the annotator rejected this document. |
meta.rejectedReason | string | Annotator’s reason given for rejecting the document. |
meta.runes | string[] | Array of runes accounting for all of the characters in the input text. Used to calculate entity annotation start and end offsets. |
[]Here is a sample output document that’s been annotated:
[]A “rune” in this context is a single highlight-able character in text, including multi-byte characters such as emoji.
[]To eliminate any ambiguity, we will treat the Swedish flag (and all other emoji and multi-byte characters) as a single atomic element.
[]As a fully managed data labeling service, Ground Truth builds training datasets for ML. For this use case, we use Ground Truth to send a collection of text documents to a pool of workers for annotation. Finally, we review for quality.
[]Ground Truth can be configured to build a data labeling job using the new NER tool as a custom template.
[]Specifically, we will:
[]A complete list of referenced resources and sample documents can be found in the following chart:
[]Ground Truth uses SageMaker labeling workforces to manage workers and distribute tasks. Create a private workforce, a worker team called ner-worker-team, and assign yourself to the team using the instructions found in Create a Private Workforce (Amazon SageMaker Console).
[]Once you’ve added yourself to a private workforce and confirmed your email, note the worker portal URL from the AWS Management Console:
[]Log in to the worker portal to view and start work on labeling tasks.
[]The Ground Truth input data manifest is a JSON-lines file where each line contains a single worker task. In our case, each line will contain a single JSON encoded Input Document containing the text that we want to annotate and the NER annotation schema.
[]Download a sample input manifest reviews.manifest from https://assets.solutions-lab.ml/NER/0.2.1/sample-data/reviews.manifest
[]Note: each row in the input manifest needs a top-level key source or source-ref. You can learn more in Use an Input Manifest File in the Amazon SageMaker Developer Guide.
[]Upload this input manifest to an S3 bucket using the AWS Management Console or from the command line, thereby replacing your-bucket with an actual bucket name.
aws s3 cp reviews.manifest s3://your-bucket/ner-input/reviews.manifest
[]Download the NER tool custom worker template from https://assets.solutions-lab.ml/NER/0.2.1/worker-template.liquid.html by viewing the source and saving the contents locally, or from the command line:
wget https://assets.solutions-lab.ml/NER/0.2.1/worker-template.liquid.html
[]Download sample pre-labeling task Lambda function: smgt-ner-pre-labeling-task-lambda.py from https://assets.solutions-lab.ml/NER/0.2.1/sample-scripts/smgt-ner-pre-labeling-task-lambda.py
[]Download sample pre-labeling task Lambda function: smgt-ner-post-labeling-task-lambda.py from https://assets.solutions-lab.ml/NER/0.2.1/sample-scripts/smgt-ner-post-labeling-task-lambda.py
[]From the AWS Management Console:
[]Once the Ground Truth job is created, we can start annotating documents. Open the worker portal for our workforce created earlier (In the AWS Management Console, navigate to the SageMaker , Ground Truth → Labeling workforces, Private, and open the Labeling portal sign-in URL )
[]Sign in and select the first labeling task in the table, and then select “Start working” to open the annotator. Perform your annotations and select submit on all three of the sample documents.
[]As Ground Truth annotators complete tasks, results will be available in the output S3 bucket:
s3://your-bucket/path-to-your-ner-job/annotations/worker-response/iteration-1/0/ []Once all tasks for a labeling job are complete, the consolidated output is available in the output.manifest file located here:
s3://your-bucket/path-to-your-ner-job/manifests/output/output.manifest []This output manifest is a JSON-lines file with one annotated text document per line in the “Output Document Format” specified previously. This file is compatible with the “Input Document Format”, and it can be fed directly into a subsequent Ground Truth job for another round of annotation. Alternatively, it can be parsed and sent to an ML training job. Some scenarios where we might employ a second round of annotations are:
[]The NER annotation tool described in this document is implemented as a custom Ground Truth annotation template. AWS customers can build their own custom annotation interfaces using the instructions found here:
[]By working together, Booking.com and the Amazon MLSL were able to develop a powerful text annotation tool that is capable of creating complex named-entity recognition and relationship annotations.
[]We encourage AWS customers with an NER text annotation use case to try the tool described in this post. If you’d like help accelerate the use of ML in your products and services, please contact the Amazon Machine Learning Solutions Lab.
[]Dan Noble is a Software Development Engineer at Amazon where he helps build delightful user experiences. In his spare time, he enjoys reading, exercising, and having adventures with his family.
[]Pri Nonis is a Deep Learning Architect at the Amazon ML Solutions Lab, where he works with customers across various verticals, and helps them accelerate their cloud migration journey, and to solve their ML problems using state-of-the-art solutions and technologies.
[]Niharika Jayanthi is a Front End Engineer at AWS, where she develops custom annotation solutions for Amazon SageMaker customers. Outside of work, she enjoys going to museums and working out.
[]Amit Beka is a Machine Learning Manager at Booking.com, with over 15 years of experience in software development and machine learning. He is fascinated with people and languages, and how computers are still puzzled by both.