DEV Community: Sujithra

Building a Smart Relocation Question Answering Bot using Hugging Face: Personalized Answers at Your Fingertips 🌍🤖💡

Sujithra — Thu, 29 Jun 2023 10:36:35 +0000

Introduction: 🌟🌈

In an increasingly globalized world, relocation has become a common phenomenon. Whether it's for work, study, or personal reasons, moving to a new country can be a daunting process. 😱🌍 From finding the right housing to understanding visa procedures and local transportation, there are numerous questions that individuals have when planning to relocate.

But fear not! 🚀🌟 To simplify this process and provide personalized assistance, we have embarked on an exciting journey of building a Smart Relocation Question Answering Bot! 🤖💪 In this blog post, we will take you on a joyride through the details of this project, exploring its architecture, features, future plans, challenges, and our valuable learnings. Buckle up! It's going to be a fun ride! 🚀🎢

Architecture Overview: 🏰📚

The Smart Relocation Question Answering Bot is built on the shoulders of giants, utilizing cutting-edge techniques from the field of natural language processing (NLP). 🤖💡 At its core, the bot harnesses the power of transformers, a groundbreaking architecture in the realm of NLP. 🌟🔮

Transformers, like magical wizards 🧙‍♂️, are capable of understanding the nuances of human speech and generating insightful responses. Our bot is powered by the illustrious BERT (Bidirectional Encoder Representations from Transformers) model, which stands as a titan among transformers. It captures deep contextual information and provides accurate answers to your burning relocation questions! 🔥🌟

Dataset: 📊🔍

To train our Smart Relocation Question Answering Bot, we have meticulously curated a comprehensive dataset that encompasses a wide range of relocation aspects.

📚🌍 It's like having an entire library 📚🌐 at your disposal, with information on housing, insurance, transportation, education, visa procedures, banking details, and more! 🏠🚗📚 Our dataset is a treasure trove of knowledge, fueling the learning process of our bot. It serves as the foundation for training BERT, allowing it to understand and respond to your relocation queries with remarkable accuracy.

The Code Magic: ✨💻🔮

Let's dive into the mystical world of code that powers our Smart Relocation Question Answering Bot. Here's a sneak peek into some of the fascinating parts:

from transformers import BertForQuestionAnswering, BertTokenizer

# Load the pre-trained BERT model and tokenizer
model = BertForQuestionAnswering.from_pretrained('bert-base-uncased')
tokenizer = BertTokenizer.from_pretrained('bert-base-uncased')

In this code snippet, we start by importing the necessary modules from the transformers library, namely BertForQuestionAnswering and BertTokenizer. These modules allow us to use the pre-trained BERT model for question-answering tasks and the associated tokenizer to preprocess the input.
We then proceed to load the pre-trained BERT model and tokenizer using the from_pretrained() method. The bert-base-uncased parameter specifies the base BERT model with uncased tokens, which means the text is lowercased during tokenization.

# Process the input question and context
question = "What are the housing options in Berlin?"
context = "Berlin offers a variety of housing options ranging from apartments in the city center to suburban houses. The rental prices vary based on location and amenities."

inputs = tokenizer.encode_plus(question, context, add_special_tokens=True, return_tensors='pt')

Next, we define a sample question and context relevant to housing options in Berlin. The question represents the user's query, while the context provides the necessary information for answering the question.
To process the input, we use the tokenizer's encode_plus() method. It tokenizes the question and context, adds special tokens like [CLS] and [SEP] to mark the beginning and separation of the input, and returns the encoded inputs as tensors.

# Get the model's predicted answer span
start_scores, end_scores = model(**inputs).start_logits, model(**inputs).end_logits
start_index = torch.argmax(start_scores)
end_index = torch.argmax(end_scores) + 1
answer = tokenizer.convert_tokens_to_string(tokenizer.convert_ids_to_tokens(inputs['input_ids'][0][start_index:end_index]))

In this part, we pass the encoded inputs through the BERT model using model(**inputs). This returns the start and end logits, representing the probabilities of each token being the start and end of the answer span within the context.
By applying torch.argmax() to the start and end logits, we obtain the indices of the most probable start and end positions of the answer span.
Finally, we convert the predicted answer span back into human-readable text using the tokenizer's convert_tokens_to_string() and convert_ids_to_tokens() methods.

Overall, the above code snippet showcases the magic of BERT in action! 🎩✨ It demonstrates how we can use the pre-trained BERT model and tokenizer from the Hugging Face library to process a question and context, and then extract the answer span. By applying this code snippet iteratively, we enable our bot to provide accurate answers to your relocation queries. It's like witnessing the convergence of code and intelligence, resulting in a remarkable solution! 💻🧠✨

Proposed AWS Services: 💻☁️

Our bot is backed by the power of Amazon Web Services (AWS) to provide you with a top-notch experience. Here's how our dream team of services works together: 🤝💡

• The User Interface (UI) interacts with Amazon Lex. 🖥️🗣️

• Amazon Lex communicates with AWS Lambda for processing and validation. 📞💪

• AWS Lambda interacts with Amazon DynamoDB for data storage, Amazon SageMaker for machine learning tasks, and Amazon S3 for static content storage. 🗄️🤖🔍💾

• And the star of the show, Amazon API Gateway, serves as the entry point for your bot, routing incoming requests to the appropriate Lambda function or SageMaker endpoint. 🚀🌟🚪🔀

Training and Learning: 🧠🔍📚

Training BERT is no small feat. It requires extensive computational power and a wealth of training data. In our case, we leveraged the Hugging Face library, a treasure chest of pre-trained transformer models and NLP tools.

🤗📚 By utilizing their state-of-the-art BERT model, we were able to accelerate our progress significantly. With Hugging Face, we embarked on a thrilling journey of transfer learning, fine-tuning BERT on our relocation dataset.

This process involved exposing BERT to our dataset and allowing it to learn the intricate patterns and nuances of relocation-related questions and answers. It's like BERT transformed into a relocation expert, absorbing the knowledge from our dataset! 🏰🌐💡

💡 Brainstorming Across Continents: Turning Ideas into Reality! 💭✨

Across continents and amidst busy schedules, our dedicated team members came together, meeting several times a week, to ignite creativity and propel our project forward. With vibrant brainstorming sessions and a virtual project board, we nurtured ideas, overcame challenges, and transformed obstacles into growth opportunities. Our meticulously crafted code now manifests our shared vision, as we embark on an exciting adventure to unravel the secrets of cutting-edge technologies.

Challenges: 🚧🤔⚡

Building a Smart Relocation Question Answering Bot comes with its fair share of challenges. One major hurdle we faced was ensuring the availability and accuracy of the relocation data. Relocation-related information is dynamic and constantly evolving, making it crucial to keep our dataset up to date.

Additionally, training BERT on such a vast dataset required substantial computational resources and time. We had to optimize our training pipeline and leverage distributed computing to overcome these challenges.

Moreover, fine-tuning BERT to understand specific relocation queries required careful experimentation and hyperparameter tuning. But through perseverance and innovative problem-solving, we triumphed over these challenges! 💪🌟

Future Plans: 🌟🚀🔮

We believe in the limitless potential of our Smart Relocation Question Answering Bot, and we have exciting plans for the future! Here's a sneak peek into what's coming next: 🔍🔮🚀

Expanded Coverage: While our bot currently focuses on Germany, we have ambitious plans to extend its coverage to more countries worldwide. From France to Japan, the world is our oyster, and we want to assist you wherever your relocation dreams take you! 🌍🌏🌐
Enhanced Embassy Information: We're working hard to provide detailed embassy information for each country. 🏛️🗺️📞 Simply provide your zip code, and our bot will serve up valuable details about the nearest embassy. This feature will make visa procedures a breeze and help you navigate the administrative aspects of relocation with ease! ✈️📋🤝

Conclusion: 🌟🔑✨

With the power of transformers, the wisdom of BERT, and the magic of Hugging Face, our Smart Relocation Question Answering Bot is ready to accompany you on your relocation journey! 🤖🌍💼 By harnessing the latest advancements in NLP and machine learning, we have created a personalized, interactive, and informative bot that will revolutionize your relocation experience. Say goodbye to confusion and hello to a seamless transition! 🚀🌈🏠🔑 So, are you ready to embark on this exciting adventure with our bot as your trusted guide? Let's make your relocation dreams come true, one question at a time! 🌍💪🔥🎉

🌟 Meet the Exceptional Leaders of our Project! 🌟

🚀 Arockia Nirmal Amala Doss (Germany) - The Spark of Inspiration: Arockia Nirmal not only shared the initial idea behind this groundbreaking project but also served as the driving force that united and inspired our entire team. With his unwavering determination, Arockia Nirmal led us towards a common goal, ensuring that every step we took was infused with passion and purpose.

🚀 Sujithra Kathiravan (USA) - A visionary with a knack for innovation, Sujithra contributed invaluable insights and spearheaded our project's strategic direction.

🌍 Felix Vidal Gutierrez Morales (Uruguay) - With his boundless enthusiasm and exceptional coding skills, Felix played a pivotal role in transforming ideas into tangible results.

🔬 Endah Bongo-Awah (Germany) - A brilliant mind with a passion for cutting-edge technologies, Endah's contributions brought depth and excellence to our project.

Together, our incredible team embarked on an exhilarating journey during the AWS Community Builders Hackathon. Despite the challenges of distance and time zones, we united our talents, met regularly, and fueled each other's creativity.

Curious to see the magic we've created? You can explore our extraordinary work on our GitHub repository:

🔗 GitHub Repo: Link to the GitHub Repo

Join us in celebrating this incredible team, as we showcase the power of community, innovation, and the AWS platform. Together, we are redefining what's possible and leaving a lasting impact on the world of AI. 🌍🚀✨

Athena Basics

Sujithra — Sun, 22 Jan 2023 19:37:46 +0000

What is Athena?
—

Interactive query service for analysis of data stored in S3
— Serverless avoiding setup of infrastructure
— Provides automatic scaling of data volume in queries
— Leverages column-based table creation for parallel processing
— Cloud based in-memory query system

Business Role for Athena
—

User friendly query system for S3 data storage
— Central metadata store architecture like Hive
— Focuses on unstructured and semi-structured data stored in S3
— Common examples of queried data include JSON, CSV,
Apache Parquet, and Apache ORC large data files
— Emphasis is on large capture data files like weblogs, IOT, and other external data

Creating Tables in Athena
—

Athena creates tables using the Apache Hive Data Definition Language
Hive is an open-source Big Data toolset for analytics
Uses SQL compliant statements for table creation

Schema on Read
—

Verifies data organization when a query is issued
— Provides much faster loading as structure is not validated
— Multiple schemas serving different needs for the same data
Better option when the schema is not known at loading time

Parallel Processing of Queries
—

Parallel operations within an SQL Query
— Concurrent users can access columns at the same time
— Horizontal and vertical parallelization of a single query operation using multiple nodes

Governed Tables

— Governed Tables are tables formed within a data lake created by AWS Lake Formation
— Similar to Managed Tables in Hive
— When a governed table is dropped the table definition in the metastore and the data file is deleted

Iceberg Table
—

An Iceberg Table is an Apache open format table designed to capture a large analytics dataset
— Manages a large collection of files as a table
— Iceberg tables must be associated with an AWS Glue catalog
— Must be created using the Parquet format in AWS
— Drop table deletes the meta store and data file

Summary

— Athena is a serverless cloud based in-memory query service
— Athena federated Query service
— Uses a common metadata store architecture for table
definitions
— Uses common data stored in JSON, ORC, and Parquet formats
— Uses standard SQL query language
— Supports external, governed, and iceberg tables

Encrypt your S3 Object

Sujithra — Mon, 31 May 2021 08:28:00 +0000

The idea behind Encrypting your S3 object is that you upload objects onto Amazon S3 and these are servers of AWS so you may want to make sure that these objects are not accessible for example, if someone gets into the Amazon servers or you wanna make sure you get adhere to some security standards set up by your company. As such, Amazon gives you four methods to encrypt objects in Amazon S3.

The first one is called SSE S3. This is to encrypt S3 objects, using keys handled and managed by AWS.
The second one is SSE-KMS. It leverages AWS key management service to manage your encryption keys.
The third one is SSE-C. It is used when you manage your own encryption keys.
Finally Client-side encryption.

Now we're going to do a deep dive on all of those so don't worry.

SSE-S3

This is an encryption where the keys used to encrypt the data are handled and managed by Amazon S3. The object is going to be encrypted server side. SSE means server-side encryption and it's type of encryption is AES-256, which is in logarithm. So for this to upload an object and set the SSE S3 encryption you must set a header called X-amz-server-side-encryption AES-256. X-amz stands for X Amazon and its server-side encryption is AES-256. This is how you remember the name of the header. Let's have a look in detail. We have an object and it is un-encrypted. We have it written out and we want to upload it into Amazon history and perform some SSE-S3 encryption. So for this we're going to upload the objects onto Amazon S3. You can use the HTTP protocol or the HTTPS protocol and you can add the header that we said, the X-amz-server-side-encryption AES256. Because of this header, Amazon S3 knows that it should apply its own S3 managed data key and using the S3 Managed Key and the object, some encryption will happen and the object will be stored encrypted into your Amazon S3 buckets. Very simple, but here in this instance the data key is entirely owned and managed by Amazon S3.

SSE-KMS

KMS is a key management service which is an encryption service. SSE-KMS is used when you have your encryption keys are handled and managed by the KMS service. Why will you use KMS over SSEs which are free? Well, it gives you control over who has access to what keys and also gives you an audit trail. Each object is going to be again encrypted server side and for this to work, we must set the header X Amazon service side encryption to be a value AWS KMS. So the idea is exactly the same because it is server-side encryption. We have the object we uploaded using HTTP and then we have the header. Amazon S3 knows to apply the KMS customer master key you have defined on top of it and using this customer master key and your object there's some encryption that will happen and the file will be stored in your S3 buckets under the SSE-KMS encryption scheme.

SSE-C

It stands for server-side encryption using the keys that you provide yourself outside of AWS. So in this case, Amazon S3 does not store the encryption key you provide so it will absolutely have to use it because it needs to do encryption after which that key will be discarded. Now, to transmit the data into AWS, you must use HTTPS because you're going to send a secret to AWS and so you must have encryption in transit. Encryption key must be provided in the HTTP headers for every HTTP request made because it's going to be discarded every single time. So we have the object and we want to have it encrypted in Amazon S3 but we want to provide ourselves the client side data key to perform the encryption. So we send both of these things over HTTPS so it's an encrypted connection between you, the clients and Amazon S3. The data key is in the header so therefore Amazon S3 received the exact same object and the client provided data key. And then again, it is server-side encryption so Amazon S3 will perform at the incorporeal using these two things and store the encrypted object into your S3 buckets. If you wanted to retrieve that file from Amazon S3 using SSE-C you would need to provide the clients' side data key that was used before. It requires a lot more management on your end because you manage to do the data keys and AWS in general does not know which data keys you have used. So it's a bit more involved.

Clients Side Encryption.

The encryption is performed by the clients. You as a client encrypt the object before uploading it into Amazon S3. Some client libraries can help you do this for example, the Amazon S3 encryption clients is a way to perform that Client Side Encryption and as I said, clients must encrypt data before sending it to S3. And then in case you receive data that is encrypted using client side encryption, then you are solely responsible for decrypting the data yourself as well so you need to make sure you have the right key available.

So, as I said, in Client Side Encryption the customer entirely manages the keys and the encryption cycle. Let's have an example. Amazon S3 this time is just the buckets where it's not doing any encryption for us because it is Client-Side Encryption not Server Side encryption. And so in the clients we'll use Encryption SDK for example, the S3 Encryption SDK will provide the object and our client's side data key. The encryption will happen client side so the object is going to be fully encrypted on the client side and then we are going to just upload that already encrypted object into Amazon S3.

Okay. So that's the four types of encryptions hopefully that makes sense.

Encryption in Transit - SSL TLS

Encryption in flight is also called SSL TLS because it uses SSL and TLS certificates. It exposes HTTP endpoint that is not encrypted and it exposes HTTPS end point which is encrypted and provide what's called encryption in flight which relies on SSL and TLS certificates. So you're free to use the end points you want but if you use the console, for example you would be using HTTPS and most clients would by the way use HTTPS endpoint by default and so if you're using HTTPS, that means that there is data transfer between your clients and Amazon S3 is going to be fully encrypted and that's, what's called encryption in transit. And one thing to know is that in case you're using SSE-C so server-side encryption and the key is provided by your clients then HTTPS is mandatory.