DEV Community: Gustavo Mainchein

Orchestrating Multi-Agent Systems with AWS Bedrock: A Comprehensive Guide

Gustavo Mainchein — Sat, 28 Jun 2025 16:46:59 +0000

Hello, fellow developers and AI enthusiasts! 👋

Today, I'm excited to dive deep into multi-agent orchestration using AWS Bedrock - a topic that's generating significant buzz in the AI community. While there are numerous approaches to implementing multi-agent systems, translating these concepts into production-ready solutions presents unique challenges that we'll address in this article.

Multi-Agent Orchestration: Powerful Use Cases

Multi-agent systems can transform how we build AI solutions by leveraging specialized components working in harmony:

Domain-Specific Expert Agents: Create agents with deep expertise in finance, healthcare, legal, or technical domains that collaborate to solve complex problems
Sequential Workflow Processing: Implement step-by-step processing where each agent handles a specific part of a complex task (e.g., one agent extracts data, another analyzes it, and a third generates recommendations)
Cognitive Diversity: Deploy agents with different reasoning approaches to tackle problems from multiple angles, similar to human team collaboration
Fallback and Redundancy Systems: Build resilient systems where specialized agents can take over when primary agents fail or encounter edge cases
Adaptive Customer Support: Route customer inquiries through a network of specialized support agents based on query complexity and domain requirements

Real-World Example: A financial advisory system where one agent specializes in investment analysis, another in tax implications, and a third in regulatory compliance - all orchestrated to provide comprehensive financial guidance.

AWS Bedrock Flow vs. Step Functions: Making the Right Choice

Technical Differences

AWS Bedrock Flow:

Purpose-built for AI agent orchestration with built-in context management
Native integration with Bedrock models and agents
Simplified prompt engineering and agent communication
Optimized for conversational and generative AI workflows
Limited to Bedrock ecosystem components

AWS Step Functions:

General-purpose workflow orchestration service
Supports integration with virtually any AWS service
Provides robust error handling and retry mechanisms
Better suited for complex business processes with diverse service requirements
Requires custom development for context management between AI components

Cost Considerations

AWS Bedrock Flow:

Pricing based on the number of orchestration steps executed
No upfront costs or minimum fees
More cost-effective for pure AI orchestration scenarios
Potentially higher costs for complex, long-running workflows

AWS Step Functions:

Pricing based on state transitions
More economical for workflows with fewer transitions but complex logic
Better cost optimization for hybrid workflows combining AI and non-AI services
Additional savings through Express Workflows for high-volume, short-duration executions

Choose Bedrock Flow for AI-centric orchestration with simpler context management, and Step Functions for complex, hybrid workflows requiring extensive AWS service integration.

Reference Architecture

AWS Lambda: Powers backend logic processing and API integrations
Bedrock Agent: Hosts our specialized domain agents with custom knowledge bases
Bedrock Prompt Management: Intelligently routes user queries to appropriate specialized agents
Bedrock Flow: Orchestrates the communication flow between agents, maintaining conversation context

The Critical Role of Agents in Bedrock Flow Implementation

Using agents to invoke Bedrock Flow addresses several critical challenges in multi-agent systems:

Session History and Context Management

When orchestrating multiple specialized agents, maintaining conversation context becomes exponentially complex. Each agent interaction builds upon previous exchanges, requiring:

Unified Context Store: Bedrock Flow maintains a centralized conversation history accessible to all agents, preventing fragmented context
State Persistence: User session state persists across the entire agent network, ensuring continuity
Memory Management: The system intelligently manages what information to retain or discard as conversations evolve
Cross-Agent References: Agents can reference information discovered by other agents without redundant user questioning

Without proper context management, multi-agent systems risk creating disjointed experiences where users must repeatedly provide the same information or where agents contradict each other due to inconsistent context understanding.

Conversation Coherence

Bedrock Flow ensures that despite involving multiple specialized agents, the conversation maintains a natural, coherent flow from the user's perspective. This prevents the jarring experience of obviously switching between different AI personalities.

Implementation Guide: Build Your Multi-Agent System

Ready to create your own multi-agent orchestration? Follow these steps:

Access the Project Repository: Clone the code to get started with the foundation

   git clone https://github.com/gugamainchein/bedrock-multi-agent-orchestration
   cd bedrock-multi-agent-orchestration

Customize Your Agents: Personalize each agent based on your specific use case requirements
- Define clear domains of expertise for each agent
- Create specialized knowledge bases
- Configure agent behaviors and response styles
Deploy Using Serverless Framework: Set up your infrastructure with minimal effort

   npm install -g serverless
   sls deploy --stage [your-stage-name]

Configure Orchestration Components: Set up the coordination layer
- Create your prompt management router with clear routing rules
- Design your Bedrock Flow to manage agent interactions
- Test the system with various user scenarios to ensure proper routing

By following this approach, you'll create a sophisticated multi-agent system that leverages the strengths of specialized AI components while maintaining a coherent user experience.

Have you implemented multi-agent systems before? What challenges did you face? I'd love to hear about your experiences in the comments!

Comparing OCR Capabilities in Amazon Bedrock LLMs: Claude 3.7 Sonnet vs. Amazon Nova Pro

Gustavo Mainchein — Thu, 01 May 2025 19:18:46 +0000

Hey there, tech enthusiasts! 👋 Ever wanted to extract text from PDF documents but found traditional OCR solutions lacking in accuracy and context understanding? That's exactly the challenge I decided to tackle in my recent project. In this article, I'll take you through my journey of comparing the OCR capabilities of two powerhouse Large Language Models available through Amazon Bedrock: Claude 3.7 Sonnet and Amazon's own Nova Pro.

The PDF Challenge: Beyond Traditional OCR

PDF documents present a unique challenge for text extraction. While they may look like simple text documents to human eyes, they're actually complex containers that can include various elements:

Text layers that may or may not be selectable
Images with embedded text
Complex layouts with tables and multi-column formats
Mixed font styles and sizes
Potential scanning artifacts

Traditional OCR tools like Tesseract often struggle with maintaining the original formatting, understanding tables, or handling lower quality scans. This is where modern multimodal LLMs enter the picture, offering a more interpretative approach to text extraction.

Project Overview: A Bedrock-Powered PDF Reader

My llms-ocr-comparation project aims to answer a specific question: how do two of Amazon Bedrock's most capable models—Claude 3.7 Sonnet and Amazon Nova Pro—compare when extracting text from PDF documents?

The project structure is straightforward:

├── documents.ipynb   # The main notebook with all code
├── documents/        # Input PDF files
├── images/           # Converted PDF pages as images
├── texts/            # Extracted text results
└── README.md

How It Works: The Technical Deep Dive

Looking at the code in documents.ipynb, we can see a well-structured pipeline for PDF text extraction:

Step 1: PDF to Image Conversion

The first step uses the PyMuPDF (fitz) library to convert each page of a PDF into a high-resolution image:

document = fitz.open("./documents/sample.pdf")

for page_number, page in enumerate(document):
    document_image = f"./images/page_{page_number + 1}.jpeg"
    pix = page.get_pixmap(alpha=False, dpi=300)
    pix.save(document_image)

This conversion is crucial because it normalizes the input for both models—whether the original PDF had selectable text or not, we're converting everything to an image to test the pure OCR capabilities of these LLMs.

Step 2: Setting Up the Models

The notebook defines two functions, one for each model:

def extract_text_with_claude_3_7_sonnet(base64_image):
    start_time = time.time()
    model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0"
    # Function code...

def extract_text_with_nova_pro(base64_image):
    start_time = time.time()
    model_id = "us.amazon.nova-pro-v1:0"
    # Function code...

What's particularly interesting is the carefully crafted prompt used for both models:

instructions = """Please extract and format the readable text from the provided image, respecting the original structure as much as possible. Follow these instructions:

- For continuous text, keep the original separation by line breaks.
- If there are tables, use Markdown syntax to present them in an organized way:

Example of expected output:

- For plain text: [Extracted text with line breaks as necessary]

- For documents with tables:
| Header1 | Header2 | Header3 |
|---------|---------|---------|
|  Data1  |  Value1 |  Value1 |
|  Data2  |  Value2 |  Value2 |

Note: Avoid adding additional interpretations or comments to the extracted content."""

This prompt does something crucial that traditional OCR tools can't do: it provides context and instructions about how to interpret and format the extracted text, particularly for tables.

Step 3: Parallel Processing with asyncio

One of the clever aspects of this implementation is the use of asyncio to process both models concurrently:

async def parallel_process():
    return await asyncio.gather(
        loop.run_in_executor(executor, extract_text_with_claude_3_7_sonnet, document_image),
        loop.run_in_executor(executor, extract_text_with_nova_pro, document_image)
    )

claude_3_7_sonnet_result, nova_pro_result = await parallel_process()

This approach maximizes efficiency by sending the same image to both models simultaneously, rather than waiting for one to complete before starting the next.

The LLM Advantage in OCR: Beyond Character Recognition

Looking at the code and the README, it's clear that this project is exploring how modern LLMs are transforming what we traditionally think of as OCR. While traditional OCR tools focus on character recognition, these LLMs are doing something much more sophisticated:

1. Contextual Understanding

Traditional OCR operates on a character-by-character or word-by-word basis. LLMs, however, can "read" the document more like a human would, using context to improve accuracy. If a character is partially obscured or ambiguous, the model can make an educated guess based on surrounding words and the overall context of the document.

2. Format Preservation

The prompt specifically instructs the models to preserve formatting, including tables. This is evident in how the models are asked to convert tables to Markdown format, maintaining the relationships between data cells—something traditional OCR often fails at.

3. Intelligent Interpretation

LLMs can distinguish between different document elements—headings, body text, tables, etc.—and format them appropriately. This level of document understanding goes well beyond simple text extraction.

The Results: Claude 3.7 Sonnet vs. Nova Pro

Looking at the output metrics from the notebook:

Claude 3.7 Sonnet:
  Input Tokens  : 1666
  Output Tokens : 1036
  Start Time    : 1746124263.978323
  End Time      : 1746124292.999416

Amazon Nova Pro:
  Input Tokens  : 2223
  Output Tokens : 971
  Start Time    : 1746124263.98382
  End Time      : 1746124279.478841

We can observe some interesting differences:

Performance Metrics

Processing Speed: Nova Pro completed the task about 13 seconds faster (15.5 seconds vs. 29 seconds for Claude)
Token Efficiency: Claude used fewer input tokens (1666 vs. 2223) but produced slightly more output tokens (1036 vs. 971)

While the README doesn't include qualitative comparisons of the actual text extraction results, these metrics alone highlight an interesting tradeoff: Nova Pro offers faster processing, while Claude appears to be more token-efficient on the input side.

The Speed vs. Accuracy Tradeoff

Based on the implementation and metrics, we can infer that there's likely a speed vs. accuracy tradeoff between these models:

Nova Pro appears optimized for speed, processing the same image in roughly half the time
Claude 3.7 Sonnet takes longer but might be doing more thorough analysis of the content

This type of comparison is exactly what makes this project valuable—understanding these tradeoffs is crucial for developers choosing the right model for their specific use case.

Practical Applications and Use Cases

The ability to accurately extract and interpret text from PDFs has numerous applications across industries:

Document Processing Automation

Legal Document Analysis: Extract clauses, terms, and key information from contracts
Financial Document Processing: Parse statements, invoices, and reports
Healthcare Records Management: Extract patient information and medical data from forms

Knowledge Management

Research Paper Analysis: Extract text and data from academic papers
Technical Documentation: Convert PDF manuals into searchable knowledge bases
Archival Digitization: Make historical documents accessible and searchable

Data Entry and Form Processing

Automated Form Data Extraction: Pull information from filled forms into databases
Receipt and Invoice Processing: Extract line items, totals, and vendor information
Business Card Information Extraction: Populate CRM systems from scanned business cards

Beyond Basic OCR: The Future is Interpretative

What makes this approach revolutionary is the shift from character recognition to document understanding. These LLMs aren't just identifying letters and words—they're interpreting documents holistically.

Intelligent Document Processing (IDP)

As mentioned in the README's contributing section, this project could be extended to include IDP comparison. This is where the real power of LLM-based OCR shines—not just extracting text but understanding document types, identifying key fields, and extracting structured information without predefined templates.

For example, given an invoice, these models could:

Recognize it as an invoice (document classification)
Extract structured data (invoice number, date, line items)
Identify relationships between data elements

Handling Edge Cases

Traditional OCR systems often fail with:

Handwritten notes
Low-quality scans
Unusual layouts
Mixed languages

LLMs excel in these scenarios because they bring human-like interpretative capabilities to the task. They can fill in gaps using context and make educated guesses about unclear content.

Implementation Best Practices from the Project

Looking at the code implementation, there are several best practices worth highlighting:

1. Well-Crafted Prompts

The detailed instructions given to both models demonstrate the importance of clear, specific prompting. By explicitly asking for table formatting in Markdown, the prompt guides the models toward a specific output format.

2. High-Resolution Image Processing

Using a 300 DPI setting for PDF page conversion ensures that the models have high-quality images to work with, improving extraction accuracy:

pix = page.get_pixmap(alpha=False, dpi=300)

3. Parallel Processing for Efficiency

The asyncio implementation allows both models to run concurrently, making the comparison more efficient:

async def parallel_process():
    return await asyncio.gather(
        loop.run_in_executor(executor, extract_text_with_claude_3_7_sonnet, document_image),
        loop.run_in_executor(executor, extract_text_with_nova_pro, document_image)
    )

4. Comprehensive Metrics Tracking

The project tracks not just the extracted text but also performance metrics like processing time and token usage, enabling quantitative comparison.

Future Extensions and Improvements

As mentioned in the README's contributing section, this project lays the groundwork for several potential improvements:

1. Evaluation Metrics

Adding formal evaluation metrics like BLEU or ROUGE would provide quantitative measures of extraction quality, especially when ground truth is available.

2. Post-Processing Optimization

The extracted text could be further processed to improve formatting, correct common OCR errors, or extract structured data into specific formats like JSON.

3. Expanded Model Comparison

Testing against other models like GPT-4 Vision or Gemini would provide a more comprehensive comparison across the LLM landscape.

4. Specialized Fine-Tuning

For specific document types or domains, fine-tuning these models could yield even better results.

Conclusion: The New Frontier of Document Understanding

This project demonstrates that we're entering a new era of document processing—one where AI doesn't just recognize text but truly understands documents. The comparison between Claude 3.7 Sonnet and Amazon Nova Pro highlights the impressive capabilities of modern LLMs in this space, while also revealing the tradeoffs developers need to consider.

For those working with document processing pipelines, the message is clear: traditional OCR is being rapidly surpassed by these more interpretative, context-aware approaches. By leveraging the document understanding capabilities of LLMs, we can create more accurate, more resilient text extraction systems.

Whether you're working with legal contracts, financial statements, or research papers, this LLM-powered approach to document processing offers significant advantages over traditional OCR. And as these models continue to improve, so too will their ability to understand and extract information from the documents that power our businesses and institutions.

Want to try it yourself? Check out the full project on GitHub and see how these powerful Amazon Bedrock models compare on your own PDFs!

Building an AI Voice Assistant Using AWS Serverless and Bedrock Nova

Gustavo Mainchein — Wed, 02 Apr 2025 11:51:47 +0000

General Context

The growing interest in natural language interfaces has made voice assistants more relevant than ever. With the rise of tools like Amazon Bedrock and the introduction of generative voices in Amazon Polly, it’s now possible to create sophisticated voice applications using entirely serverless infrastructure.

In this article, I’ll walk you through the architecture and implementation of an AI voice assistant that listens to your voice, transcribes your question, uses a generative model to understand and respond, and finally speaks the answer back to you. The whole solution is built using AWS serverless services, making it scalable, cost-effective, and easy to deploy.

You can find the complete project repository on GitHub.

Deep Dive on AWS Resources

To create this voice assistant, I used a combination of AWS services that seamlessly interact:

Amazon S3:

Stores the audio files and acts as the glue for processing. It temporarily holds the user's recorded voice (WebM format) and also the synthesized audio response.

Amazon Transcribe:

Transcribes the uploaded audio into text using its real-time transcription API. It supports various languages and accents, and it integrates well with other AWS services in the workflow.

Amazon Bedrock (Nova Micro):

This is the brain of the application. The transcribed text is sent to a foundation model hosted on Amazon Bedrock—in this case, Nova Micro. It generates a coherent and human-like response based on the user’s input.

Amazon Polly (Generative Voice):

Once the response text is generated, Amazon Polly converts it into audio using one of the new generative voices, delivering a more natural, expressive tone compared to traditional TTS.

AWS Lambda:

Orchestrates the entire process:

Triggered by S3 uploads
Calls Amazon Transcribe and waits for transcription
Sends prompt to Bedrock and receives the response
Converts response text to speech with Polly
Returns a signed URL to the audio for playback

Amazon API Gateway:

Exposes the backend as a secure REST API. It allows the front-end to send the user’s voice and receive the audio response.

Deep Dive on Application

The front-end is a simple JavaScript application that records the user’s voice via the browser, sends it to the backend, and plays the response. It includes:

Audio recording using MediaRecorder
File upload to an S3 presigned URL
Asynchronous polling until the processed voice response is ready
Playback of Polly's generative voice output

The back-end architecture follows an event-driven pattern:

User speaks a question.
Audio is uploaded to S3.
Lambda is triggered on object creation.
Audio is transcribed using Amazon Transcribe.
Text is sent to Bedrock Nova Micro for a response.
The response is synthesized into speech using Amazon Polly generative voices.
A signed URL is returned to the front-end.

All services are defined in infrastructure-as-code via the AWS Serverless Framework, making the deployment repeatable and easy to manage.

Cost Estimate

Here’s a rough cost estimate based on moderate usage (100 requests/day):

Amazon S3 | 1 GB storage, 5K PUT/GET | ~$0,14
Amazon Transcribe | 10 hours/month | ~$0,24
Amazon Bedrock (Nova Micro) | 500K input/output tokens | ~$0,09
Amazon Polly (Generative) | 10 hours of audio | ~$0,00
Lambda (1M requests + 5000 ms + 128 MB) | ~$3.00
API Gateway | 1M calls/month | ~$3.50

💡 Total Estimated Monthly Cost: ~$9,56

You can tweak your usage and run your own estimate using the AWS Pricing Calculator.

Final Considerations

This project showcases how powerful AWS serverless technologies can be when building modern, AI-powered voice interfaces. By leveraging Amazon Polly's new generative voices, Bedrock’s advanced language models, and an event-driven architecture, you can create a seamless voice assistant with very low overhead.

The best part? It scales effortlessly—whether you're running one or 10,000 daily conversations.

I encourage you to explore the GitHub repo, fork it, and make it your own. You can easily swap out the voice model, add authentication with Cognito, or even extend it to support multi-turn conversations.

Feel free to leave questions or feedback in the comments!

References

🔗 Project GitHub Repository: https://github.com/gugamainchein/ai-voice-assistance

🧠 Amazon Bedrock Nova: https://docs.aws.amazon.com/nova/latest/userguide/what-is-nova.html

🔊 Amazon Polly (Generative Voices): https://docs.aws.amazon.com/polly/latest/dg/generative-voices.html

📝 Amazon Transcribe: https://aws.amazon.com/transcribe/

GitHub - Improve your Code with DeepSeek and Serverless App

Gustavo Mainchein — Mon, 17 Mar 2025 01:56:21 +0000

Introduction

As software development grows in complexity, maintaining clean, efficient, and well-structured code becomes a major challenge. Poorly written code can lead to increased maintenance costs, decreased readability, and technical debt. With generative AI, developers now have access to intelligent code analysis tools that provide feedbacks and actionable improvements.

This post is about a serverless application that use AWS Bedrock with DeepSeek R1 LLM to analyze GitHub commits, detect potential issues, and suggest improvements based on Domain-Driven Design (DDD) and Clean Code principles. This approach ensures that code remains scalable, maintainable, and aligned with best practices.

By leveraging AWS Bedrock, this project achieves seamless AI integration within a serverless architecture, ensuring cost-effectiveness, performance, and reliability.

About This Project

Overview

This project is designed to automate code analysis in a GitHub repository. Every time a developer pushes a commit, a GitHub webhook triggers an AWS Lambda function, which then analyzes the commit and provides feedback using DeepSeek R1 LLM.

Key Technologies

Serverless Framework: Manages and deploys AWS resources, including Lambda, API Gateway, and DynamoDB.
AWS Lambda: Processes GitHub webhooks and triggers AI-based code validation.
DeepSeek R1 LLM: A generative AI model that analyzes commit changes and suggests improvements.
DynamoDB: Stores commit metadata and AI-generated recommendations for future reference.
CloudWatch: Provides logging and monitoring for the Lambda functions.
GitHub Webhooks: Automatically sends commit data to the API for processing.

Project Structure Breakdown

The project is structured into several key components, each responsible for handling a specific part of the process:

├── layers/                 # Shared dependencies for Lambda functions
│   ├── common/
│   │   ├── requirements.txt # Defines Python dependencies
├── src/
│   ├── functions/          # Lambda functions that process GitHub webhooks
│   │   ├── commit_analyzer.py # Analyzes commit data and sends it to DeepSeek AI
│   ├── helpers/            # Utility classes for handling Lambda payloads and responses
│   │   ├── lambda_payload.py
│   │   ├── lambda_response.py
│   ├── infrastructure/     # YAML configurations for AWS resource deployment
│   │   ├── resources.yml
│   ├── services/           # External service integrations (GitHub, DynamoDB, AI model)
│   │   ├── bedrock.py      # Handles AWS Bedrock interactions
│   │   ├── dynamodb.py     # Interfaces with DynamoDB to store results
│   │   ├── github.py       # Manages GitHub structure returns
│   ├── __init__.py
├── .env.example            # Example environment configuration file
├── deploy-example.sh       # Deployment script for easy setup
├── README.md               # Documentation for the project
├── serverless.yml          # Serverless Framework configuration file

How It Works

A developer commits changes to the repository.
GitHub sends a webhook event to the API Gateway.
The API Gateway triggers an AWS Lambda function.
The Lambda function analyzes the commit and extracts relevant code changes.
The extracted code is processed by DeepSeek R1 LLM for improvement suggestions.
The AI-generated recommendations are stored in DynamoDB for reference.
The developer receives feedback on code quality and best practices.

API Testing Example

To test the AI-based code analysis manually, you can use the following cURL request:

curl --location --request POST 'https://example.com/commit/analyze' \
--header 'Content-Type: application/json' \
--data-raw '{
  "ref": "refs/heads/develop",
  "before": "a1b2c3d4e5f678901234567890abcdef12345678",
  "after": "f1e2d3c4b5a678901234567890abcdef98765432",
  "repository": {
    "id": 123456789,
    "node_id": "R_kgDOPQRSTU",
    "name": "fake-repo",
    "full_name": "johnDoe/fake-repo",
    "private": false,
    "owner": {
      "name": "johnDoe",
      "email": "johndoe@users.noreply.github.com",
      "login": "johnDoe",
      "id": 987654321,
      "node_id": "MDQ6VXNlcjk4NzY1NDMyMQ==",
      "avatar_url": "https://avatars.githubusercontent.com/u/987654321?v=4",
      "gravatar_id": "",
      "url": "https://api.github.com/users/johnDoe",
      "html_url": "https://github.com/johnDoe",
      "followers_url": "https://api.github.com/users/johnDoe/followers",
      "following_url": "https://api.github.com/users/johnDoe/following{/other_user}",
      "gists_url": "https://api.github.com/users/johnDoe/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/johnDoe/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/johnDoe/subscriptions",
      "organizations_url": "https://api.github.com/users/johnDoe/orgs",
      "repos_url": "https://api.github.com/users/johnDoe/repos",
      "events_url": "https://api.github.com/users/johnDoe/events{/privacy}",
      "received_events_url": "https://api.github.com/users/johnDoe/received_events",
      "type": "User",
      "user_view_type": "public",
      "site_admin": false
    },
    "html_url": "https://github.com/johnDoe/fake-repo",
    "description": "A fake repository for testing purposes",
    "fork": false,
    "url": "https://github.com/johnDoe/fake-repo",
    "created_at": 1742164973,
    "updated_at": "2025-03-16T22:42:57Z",
    "pushed_at": 1742165040,
    "git_url": "git://github.com/johnDoe/fake-repo.git",
    "ssh_url": "git@github.com:johnDoe/fake-repo.git",
    "clone_url": "https://github.com/johnDoe/fake-repo.git",
    "svn_url": "https://github.com/johnDoe/fake-repo",
    "size": 100,
    "stargazers_count": 10,
    "watchers_count": 10,
    "language": "JavaScript",
    "has_issues": true,
    "has_projects": true,
    "has_downloads": true,
    "has_wiki": true,
    "has_pages": false,
    "has_discussions": false,
    "forks_count": 2,
    "archived": false,
    "disabled": false,
    "open_issues_count": 1,
    "license": "MIT",
    "allow_forking": true,
    "is_template": false,
    "visibility": "public",
    "default_branch": "develop"
  },
  "pusher": {
    "name": "johnDoe",
    "email": "johndoe@users.noreply.github.com"
  },
  "sender": {
    "login": "johnDoe",
    "id": 987654321,
    "node_id": "MDQ6VXNlcjk4NzY1NDMyMQ==",
    "avatar_url": "https://avatars.githubusercontent.com/u/987654321?v=4",
    "url": "https://api.github.com/users/johnDoe",
    "html_url": "https://github.com/johnDoe",
    "followers_url": "https://api.github.com/users/johnDoe/followers",
    "following_url": "https://api.github.com/users/johnDoe/following{/other_user}",
    "gists_url": "https://api.github.com/users/johnDoe/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/johnDoe/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/johnDoe/subscriptions",
    "organizations_url": "https://api.github.com/users/johnDoe/orgs",
    "repos_url": "https://api.github.com/users/johnDoe/repos",
    "events_url": "https://api.github.com/users/johnDoe/events{/privacy}",
    "received_events_url": "https://api.github.com/users/johnDoe/received_events",
    "type": "User",
    "user_view_type": "public",
    "site_admin": false
  },
  "created": false,
  "deleted": false,
  "forced": false,
  "base_ref": null,
  "compare": "https://github.com/johnDoe/fake-repo/compare/a1b2c3d4e5f6...f1e2d3c4b5a6",
  "commits": [
    {
      "id": "f1e2d3c4b5a678901234567890abcdef98765432",
      "tree_id": "5a6b7c8d9e0f1234567890abcdef987654321234",
      "distinct": true,
      "message": "fix: updated authentication logic",
      "timestamp": "2025-03-16T19:44:00-03:00",
      "url": "https://github.com/johnDoe/fake-repo/commit/f1e2d3c4b5a678901234567890abcdef98765432",
      "author": {
        "name": "John Doe",
        "email": "johndoe@users.noreply.github.com",
        "username": "johnDoe"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "username": "web-flow"
      },
      "added": ["src/auth.js"],
      "removed": [],
      "modified": ["src/index.js"]
    }
  ],
  "head_commit": {
    "id": "f1e2d3c4b5a678901234567890abcdef98765432",
    "tree_id": "5a6b7c8d9e0f1234567890abcdef987654321234",
    "distinct": true,
    "message": "fix: updated authentication logic",
    "timestamp": "2025-03-16T19:44:00-03:00",
    "url": "https://github.com/johnDoe/fake-repo/commit/f1e2d3c4b5a678901234567890abcdef98765432",
    "author": {
      "name": "John Doe",
      "email": "johndoe@users.noreply.github.com",
      "username": "johnDoe"
    },
    "committer": {
      "name": "GitHub",
      "email": "noreply@github.com",
      "username": "web-flow"
    },
    "added": ["src/auth.js"],
    "removed": [],
    "modified": ["src/index.js"]
  }
}'

Upon execution, the request triggers the AI-powered analysis, and you will receive a detailed JSON response with suggested improvements for your committed code.

How to Configure GitHub Webhooks

To enable automated AI code validation in your repository, follow these steps:

Navigate to your repository on GitHub.
Click on Settings > Webhooks.
Click "Add Webhook".
Set the Payload URL: https://example.com/commit/analyze.
Choose Content Type: application/json.
Select the events that trigger the webhook: Push events.
Click "Add Webhook" to save the configuration.

Now, every new commit automatically triggers the AI analysis, and improvement suggestions will be generated.

Conclusion

This project showcases how generative AI can revolutionize software development by providing real-time feedback on code quality. By using AWS Bedrock with DeepSeek R1 LLM, this solution ensures:

Consistent adherence to best coding practices
Improved readability and maintainability of code
Automated, AI-driven reviews that enhance development workflows

Developers can now spend less time debugging and more time building high-quality software.

To explore the full project, visit: GitHub IA - Code Validation.

Note: The DeepSeek R1 LLM is a recent model in the AWS marketplace and in the market, so its use may have quality issues, especially for languages other than English and Chinese.

Serverless App - Extração de Textos com Exibição de Layouts com Textract

Gustavo Mainchein — Mon, 07 Oct 2024 12:19:35 +0000

Entendendo o Textract:

O Amazon Textract é um serviço avançado de Machine Learning (ML) da AWS projetado para extrair automaticamente textos impressos ou manuscritos, além de identificar elementos de layout e dados estruturados a partir de documentos digitalizados. Ele é capaz de processar diversos tipos de documentos, como formulários, relatórios e recibos, facilitando a automação de tarefas que exigem a extração e organização de informações. A tecnologia é particularmente útil em cenários onde grandes volumes de documentos precisam ser analisados, permitindo uma leitura precisa e eficiente dos conteúdos, sejam eles simples ou complexos.

A base desse serviço é a tecnologia de reconhecimento óptico de caracteres (OCR), que utiliza algoritmos sofisticados de correspondência de padrões para analisar imagens de texto. O OCR realiza uma comparação detalhada, caractere por caractere, entre o conteúdo visualizado e um banco de dados interno, decodificando a imagem para gerar um texto digital legível. No entanto, o OCR convencional pode ser limitado quando se trata de interpretar variações complexas de escrita, especialmente manuscrita. Para superar esses desafios, o Amazon Textract adota o reconhecimento inteligente de caracteres (ICR), uma evolução do OCR. O ICR utiliza técnicas avançadas de machine learning que treinam o sistema para reconhecer caracteres da mesma forma que um humano faria, aprimorando a precisão na leitura de diferentes estilos de escrita, mesmo em formatos menos padronizados.

"Antes de prosseguirmos, é fundamental esclarecer o objetivo desta publicação. Vamos apresentar um exemplo prático de como desenvolver tanto o back-end quanto o front-end para integrar o Amazon Textract, com o foco específico em destacar informações importantes (highlights) em documentos PDF. Isso será feito utilizando o recurso de Layout do serviço, que permite identificar e manipular a estrutura visual dos documentos, como tabelas, parágrafos e outras áreas de interesse. Vale ressaltar que, neste conteúdo, não exploraremos outras funcionalidades do Textract, concentrando-se exclusivamente na extração de layout e destaques em PDFs.”

Como funciona a integração com o Textract:

A AWS possui diversos portais que contém documentações completas sobre o processo de integração com cada serviço, de acordo com sua linguagem. No nosso caso, iremos utilizar o Node.js, que é um software de código aberto, multiplataforma, baseado no interpretador V8 do Google e que permite a execução de códigos JavaScript fora de um navegador web.

No caso do Javascript, a AWS possui um hub grande de integrações, onde você pode realizar a integração com os serviços por meio de módulos. Pensando na integração com o Textract, você pode seguir a documentação e executar os seguintes comandos de instalação:

Nesta publicação, iremos utilizar o método "AnalyzeDocumentCommand” da API do Textract, cuja documentação deixo ao lado: https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/textract/command/AnalyzeDocumentCommand/

Aplicação Back-End:

Para estruturarmos a aplicação back-end, iremos contar com a utilização do Serverless Framework como biblioteca e framework de projeto, pois essa solução irá nos apoiar nas configurações dos recursos da Infraestrutura e publicação das funções Lambda e API Gateway.

Começando pelo arquivo serverless.yml, temos:

# Nome da organização da conta to Serverless Framework
org: publicacao
# Nome da aplicação presente na organização
app: documents-analyze
# Nome do serviço pertencente à aplicação
service: back-end

provider:
  # Nome do provider de infraestrutura
  name: aws
  # Linguagem e versão aceita pelo Lambda
  runtime: nodejs20.x
  # Timeout default das funções Lambda
  timeout: 30
  # Estrutura da role de IAM para permissionamento das funções Lambda
  iamRoleStatements:
    - Resource: "*"
      Effect: Allow
      Action:
        - s3:*
        - textract:*

plugins:
  # Plugin (módulo NPM) para apoiar na execução em ambiente de desenvolvimento
  - serverless-offline

# Estruturação das funções Lambda
functions:
  # Nome único da função Lambda
  extractText:
    # Caminho de pastas que a função se encontra
    handler: src/extractText.handler
    # Eventos que serão o gatilho para triggar a função, no caso aqui é o API Gateway
    events:
      - httpApi:
          path: /{documentName}
          method: get

Seguindo para configuração do arquivo package.json (arquivo padrão para execução de aplicações Node.js):

{
  "name": "back-end",
  "version": "1.0.0",
  "main": "src/extractText.mjs",
  "license": "ISC",
  "type": "module",
  "dependencies": {
    "@aws-sdk/client-s3": "^3.658.1",
    "@aws-sdk/client-textract": "^3.658.1",
    "@aws-sdk/s3-request-presigner": "^3.658.1"
  },
  "devDependencies": {
    "serverless-offline": "^14.3.2"
  }
}

Agora, no arquivo src/extractText.mjs, temos:

```import import {
TextractClient,
AnalyzeDocumentCommand,
} from "@aws-sdk/client-textract";
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

// Infrastructure Layer
const region = "us-east-1";
const textractClient = new TextractClient({ region });
const s3Client = new S3Client({ region });

const BUCKET_NAME = "";
const DOCUMENTS_FOLDER = "";
const SIGNED_URL_EXPIRATION = 3600;

// Service Layer: Handles Textract document analysis
const analyzeDocument = async (bucketName, documentPath) => {
const command = new AnalyzeDocumentCommand({
Document: {
S3Object: {
Bucket: bucketName,
Name: documentPath,
},
},
FeatureTypes: ["LAYOUT"],
});

const response = await textractClient.send(command);
return {
blocks: response.Blocks,
pages: response.DocumentMetadata?.Pages,
};
};

// Service Layer: Generates signed URL for S3 object
const generateSignedUrl = async (bucketName, documentPath) => {
const command = new GetObjectCommand({
Bucket: bucketName,
Key: documentPath,
});

return getSignedUrl(s3Client, command, { expiresIn: SIGNED_URL_EXPIRATION });
};

// Domain Layer: Main handler function
const handler = async (event) => {
try {
const { documentName } = event.pathParameters;
const documentParsedName = decodeURIComponent(documentName) + ".pdf";
const documentPath = ${DOCUMENTS_FOLDER}/${documentParsedName};

const documentData = await analyzeDocument(BUCKET_NAME, documentPath);
const signedUrl = await generateSignedUrl(BUCKET_NAME, documentPath);

return createSuccessResponse({ documentData, signedUrl });

} catch (error) {
console.error("Error processing document:", error);
return createErrorResponse("Failed to process document.");
}
};

// Helper functions: Response formatting
const createSuccessResponse = (data) => ({
statusCode: 200,
body: JSON.stringify(data),
});

const createErrorResponse = (message) => ({
statusCode: 500,
body: JSON.stringify({ error: message }),
});

export { handler };




Com isso, no back-end está devidamente estruturado e para você executá-lo localmente, siga os comandos abaixo:

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/al1kr2fth75x5i1jbsfa.png)

A partir de então, você estará apto a fazer requisições na sua rota local a partir de qualquer navegador ou plataforma de API, como [Postman](https://www.postman.com/) ou [Apidog](https://apidog.com/).

**Aplicação Front-End:**

Para estruturação da aplicação Front-End, utilizamos o Tailwindcss + Vite + React TS, onde você pode encontrar o tutorial de inicialização do projeto na seguinte documentação: https://tailwindcss.com/docs/guides/vite

Após o passo-a-passo acima executado, seu projeto precisará de algumas dependências para exibir os PDFs em tela, assim como os highlights nos textos. Pensando nisso, utilizaremos a biblioteca react-pdf para podermos fazer esse processo no Front-End.

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gf7afqr4xwg7i6dda6ii.png)

Lembre-se de instalar a biblioteca como super usuário, pois ela utiliza configurações de sistema para realizar a exibição do documento.

Com isso feito, você precisará apenas criar um arquivo de componente e alterar o App.tsx, conforme orientações abaixo:

- Começando pela criação do src/components/TextDetection.tsx, que será o responsável pela exibição do PDF e marcação das caixas de posição das extrações:



```import import React, { useEffect, useRef, useState } from "react";
import { Props } from "../@types/blocks";
import { pdfjs } from "react-pdf";
import "react-pdf/dist/esm/Page/AnnotationLayer.css";
import "react-pdf/dist/esm/Page/TextLayer.css";

// Configuração do worker do PDF.js
pdfjs.GlobalWorkerOptions.workerSrc = new URL(
  "pdfjs-dist/build/pdf.worker.min.mjs",
  import.meta.url
).toString();

// Função para detectar cliques em caixas delimitadoras
const handleBoxClick = (
  e: MouseEvent,
  block: any,
  width: number,
  height: number,
  setModalText: (text: string) => void
) => {
  const canvas = e.target as HTMLCanvasElement;
  const rect = canvas.getBoundingClientRect();

  const x = e.clientX - rect.left;
  const y = e.clientY - rect.top;

  const box = block.Geometry.BoundingBox;
  const left = width * box.Left;
  const top = height * box.Top;
  const boxWidth = width * box.Width;
  const boxHeight = height * box.Height;

  if (x >= left && x <= left + boxWidth && y >= top && y <= top + boxHeight) {
    setModalText(block.Text);
  }
};

// Função para desenhar as caixas delimitadoras
const drawBoundingBoxes = (
  ctx: CanvasRenderingContext2D,
  width: number,
  height: number,
  canvas: HTMLCanvasElement,
  response: Props["response"],
  setModalText: (text: string) => void
) => {
  response.blocks.forEach((block) => {
    if (block.BlockType === "LINE") {
      const box = block.Geometry.BoundingBox;
      const left = width * box.Left;
      const top = height * box.Top;
      ctx.strokeStyle = "red";
      ctx.lineWidth = 2;
      ctx.strokeRect(left, top, width * box.Width, height * box.Height);

      canvas.addEventListener("click", (e) =>
        handleBoxClick(e, block, width, height, setModalText)
      );
    }
  });
};

// Serviço para carregar o PDF e desenhar caixas delimitadoras
const loadPdfAndDraw = async (
  documentUrl: string,
  canvasRefs: React.MutableRefObject<HTMLCanvasElement[]>,
  response: Props["response"],
  setModalText: (text: string) => void
) => {
  try {
    const pdf = await pdfjs.getDocument(documentUrl).promise;

    for (let pageNumber = 1; pageNumber <= pdf.numPages; pageNumber++) {
      const page = await pdf.getPage(pageNumber);
      const viewport = page.getViewport({ scale: 1 });

      const canvas = canvasRefs.current[pageNumber - 1];
      if (!canvas) continue;

      const ctx = canvas.getContext("2d");
      if (!ctx) continue;

      canvas.width = viewport.width;
      canvas.height = viewport.height;

      await page.render({ canvasContext: ctx, viewport }).promise;
      drawBoundingBoxes(
        ctx,
        viewport.width,
        viewport.height,
        canvas,
        response,
        setModalText
      );
    }
  } catch (error) {
    console.error("Erro ao carregar o PDF:", error);
  }
};

// Componente principal
const TextDetectionCanvas: React.FC<Props> = ({
  response,
  documentUrl,
  qtdPages,
}) => {
  const canvasRefs = useRef<HTMLCanvasElement[]>([]);
  const [modalText, setModalText] = useState<string | null>(null);

  const closeModal = () => setModalText(null);

  useEffect(() => {
    if (documentUrl && response) {
      loadPdfAndDraw(documentUrl, canvasRefs, response, setModalText);
    }
  }, [documentUrl, response]);

  return (
    <div>
      {/* Renderizar os canvas */}
      {Array.from({ length: qtdPages }).map((_, index) => (
        <canvas key={index} ref={(el) => (canvasRefs.current[index] = el!)} />
      ))}

      {/* Modal de texto */}
      {modalText && <TextModal modalText={modalText} closeModal={closeModal} />}
    </div>
  );
};

// Componente para o modal de texto
const TextModal: React.FC<{ modalText: string; closeModal: () => void }> = ({
  modalText,
  closeModal,
}) => (
  <div
    style={{
      position: "fixed",
      top: 0,
      left: 0,
      width: "100vw",
      height: "100vh",
      backgroundColor: "rgba(0, 0, 0, 0.5)",
      display: "flex",
      alignItems: "center",
      justifyContent: "center",
      zIndex: 1000,
    }}
  >
    <div
      style={{
        backgroundColor: "white",
        padding: "20px",
        borderRadius: "8px",
        boxShadow: "0 2px 10px rgba(0, 0, 0, 0.3)",
      }}
    >
      <div className="font-bold text-2xl flex gap-10">
        <h1>Veja os Detalhes</h1>
        <button onClick={closeModal}>X</button>
      </div>
      <p className="mt-5">Texto: {modalText}</p>
    </div>
  </div>
);

export default TextDetectionCanvas;

Agora finalizando com a alteração do App.tsx, que será o responsável por fazer a integração com o Back-End a partir de uma lista de documentos:

```import import React, { useEffect, useState } from "react";
import TextDetectionCanvas from "./components/TextDetection";
import { Response } from "./@types/blocks";

// Constants
const DOCUMENTS = [
"LISTA DE DOCUMENTOS"
];

// Service Layer: Handles document fetching
const fetchDocumentData = async (
documentName: string,
setDocumentData: (data: Response) => void,
setDocumentUrl: (url: string) => void,
setPageNumber: (page: number) => void
) => {
try {
const response = await fetch(http://localhost:3000/${documentName});
const data = await response.json();
setDocumentData(data.documentData);
setPageNumber(data.documentData.pages);
setDocumentUrl(data.signedUrl);
} catch (error) {
console.error("Failed to fetch document data", error);
}
};

// Domain Layer: Main Application Component
const App: React.FC = () => {
const [documentData, setDocumentData] = useState();
const [documentUrl, setDocumentUrl] = useState("");
const [pageNumber, setPageNumber] = useState(1);
const [selectedDocument, setSelectedDocument] = useState(
DOCUMENTS[0]
);

// Fetch document data whenever the selected document changes
useEffect(() => {
setPageNumber(0);
setDocumentUrl("");
fetchDocumentData(
selectedDocument,
setDocumentData,
setDocumentUrl,
setPageNumber
);
}, [selectedDocument]);

return (

documents={DOCUMENTS}
selectedDocument={selectedDocument}
onDocumentSelect={setSelectedDocument}
/>
{documentUrl === "" ? (

Carregando...

) : (
documentData={documentData}
documentUrl={documentUrl}
pageNumber={pageNumber}
/>
)}

);
};

// UI Layer: Document Selector Component
const DocumentSelector: React.FC<{
documents: string[];
selectedDocument: string;
onDocumentSelect: (doc: string) => void;
}> = ({ documents, selectedDocument, onDocumentSelect }) => (

value={selectedDocument}
onChange={(e) => onDocumentSelect(e.target.value)}
>
{documents.map((document, index) => (

{document}

))}

);

// UI Layer: Document Viewer Component
const DocumentViewer: React.FC<{
documentData: Response | undefined;
documentUrl: string;
pageNumber: number;
}> = ({ documentData, documentUrl, pageNumber }) => (

response={documentData as Response}
documentUrl={documentUrl}
qtdPages={pageNumber}
/>

);

export default App;




Com as configurações realizadas, basta iniciar seu projeto por meio dos comandos abaixo:

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2rjgbynl3gs0trjzr0zq.png)

**Resultado Final:**

Após a execução de todos os passos acima, você irá ter uma aplicação funcional que estará analisando os documentos, extraindo os textos e informando as posições onde encontram-se cada marcação daquele texto no PDF.

Exemplo do resultado final:

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c4efvwo0ageyidi2s1c3.png)

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7a5k09uto60g27igemee.png)

Pensando até mesmo em evoluções futuras, como trata-se de uma solução de OCR e sabemos que erros podem ocorrer, você pode contar com a utilização de um LLM e uma base de conhecimento para poder indexar esses textos, corrigi-los e gerar respostas inteligentes a partir de determinado assunto.

Com isso, notamos que a aplicação *serverless* desenvolvida para extração de textos e exibição de layouts com Amazon Textract demonstrou uma solução eficaz para automatizar a análise de documentos em larga escala. Utilizando OCR avançado e ICR, a ferramenta não apenas extrai informações textuais, mas também identifica e organiza estruturas complexas, como tabelas e parágrafos, diretamente em PDFs. Com a integração entre o *back-end* (Node.js e Serverless Framework) e o *front-end* (React, Vite e TailwindCSS), a aplicação permite uma visualização intuitiva das marcações e dos textos extraídos.

Amazon Monitron - Monitoramento Inteligente para Indústria

Gustavo Mainchein — Mon, 02 Sep 2024 11:56:09 +0000

Sobre o Serviço:

O Amazon Monitron é uma solução avançada de monitoramento que utiliza sensores inteligentes para acompanhar o desempenho de motores e outros equipamentos industriais. Esses sensores são especialmente eficazes em máquinas com componentes rotativos, como motores elétricos e bombas, onde o movimento rotacional é um fator crítico. O sistema coleta dados detalhados sobre a vibração e a temperatura do equipamento em tempo real, permitindo a análise contínua do seu estado de funcionamento. Com base nesses dados, o Amazon Monitron emprega algoritmos de aprendizado de máquina para realizar análises preditivas, identificando possíveis falhas ou a necessidade de manutenções preventivas antes que ocorram problemas graves. Dessa forma, a solução ajuda a minimizar o tempo de inatividade não planejado e a otimizar o desempenho operacional dos equipamentos.

Cada kit do Amazon Monitron conta com:

5 Sensores de coleta;
1 Central de comunicação com a cloud AWS;
1 Fonte com 3 adaptadores de entrada.

Como funciona:

Após receber o kit do Amazon Monitron, o processo de instalação é bastante simples e intuitivo. Primeiro, faça o download do aplicativo do Amazon Monitron a partir da loja de aplicativos do seu dispositivo móvel, disponível na Apple ou no Android. Em seguida, autentique-se usando sua conta AWS e escolha o site (ou local / grupo) de instalação onde os sensores serão utilizados. A partir deste ponto, você pode começar a cadastrar os diferentes equipamentos que deseja monitorar, especificando também as diversas posições dentro desses equipamentos onde os sensores serão instalados. O aplicativo facilita a sincronização dos sensores com a central de coleta de dados, garantindo que todas as informações sejam capturadas e transmitidas corretamente para análise.

Demonstração da instalação dos sensores do Amazon Monitron, você encontrará um esquema detalhado de cada passo do processo de instalação.

Antes de finalizar a instalação do Amazon Monitron, é crucial definir uma estratégia clara para o posicionamento dos sensores em cada motor. A configuração inicial é extremamente importante, pois qualquer alteração na posição de um sensor após a instalação pode resultar em desvios nos dados coletados e falta de padronização, comprometendo a precisão da análise. Portanto, escolha cuidadosamente os pontos de instalação para garantir que os sensores capturem informações relevantes e consistentes sobre o desempenho do equipamento.

Uma vez que os sensores estejam instalados e sincronizados corretamente, o painel da AWS começará a receber dados de vibração e temperatura dos equipamentos a cada uma hora, um intervalo fixo e não personalizável. Para obter resultados precisos na análise preditiva de manutenções e falhas, é ideal que a solução permaneça instalada nos motores por um período prolongado. Esse tempo é essencial para acumular uma quantidade significativa de dados, permitindo a identificação de padrões de comportamento normal e anormal dos motores. Com isso, a solução pode gerar alertas e avisos mais precisos, contribuindo para uma manutenção mais eficiente e redução de paradas não planejadas.

Peculiaridades do serviço:

O Amazon Monitron foi projetado para ter uma longa duração, com qualidade de coleta e resistencia à diversos ambientes. Contudo, para atender tal finalidade, o serviço conta com as seguintes peculiaridades dos sensores:

Intervalo de coleta: a cada 1h
Temperatura suportada: Intervalo entre -20ºC / +80ºC
Sensor de vibração: Acelerômetro MEMS de 3 eixos, faixa +/-16g, frequência de resposta de até 1KHz, taxa de dados de saída de 6,6KHz
Tempo de vida da bateria: Estimado em até 5 anos (dependendo do ambiente em que o sensor se encontra)
Dimensões: 52.8 x 43.0 x 24.9 mm / 2.08 x 1.69 x 0.98 inch
Peso: 55g

Além dos pontos citados acima, é muito importante que você mantenha a rede, em que o serviço irá operar, de forma segura, tendo como apoio a seguinte configuração de liberação necessária para o correto funcionamento da comunicação entre o Gateway e a AWS: https://docs.aws.amazon.com/Monitron/latest/user-guide/network-secure.html

Possibilidades de integrações:

Como um serviço gerenciado da AWS, o Amazon Monitron oferece integrações facilitadas com diversos recursos da AWS, como o Kinesis Data Stream e o Firehose. Essas integrações permitem que os dados capturados pelos sensores sejam transmitidos e armazenados no Amazon S3 no formato JSON Lines (JSONL), um formato eficiente para o processamento e análise de grandes volumes de dados.

Com os dados armazenados no S3, as possibilidades de integração são amplas e versáteis, permitindo a criação de soluções personalizadas para diferentes necessidades de análise e visualização. Algumas das integrações possíveis incluem:

Disponibilização de APIs: Utilizando o AWS Athena, é possível criar APIs para consulta e consumo dos dados diretamente no S3, facilitando o acesso e a análise dos dados de monitoramento.
Integração com Amazon Bedrock Agents e Action Groups: Essa integração permite a execução de consultas no AWS Athena e a construção de respostas inteligentes baseadas em dados, otimizando a tomada de decisões e o monitoramento automatizado.
Construção de soluções de Business Intelligence (BI): Com o Amazon QuickSight, é possível desenvolver dashboards e relatórios interativos para visualização e análise dos dados, transformando informações em insights acionáveis.
Outras integrações: Além das mencionadas, há diversas outras possibilidades de integração com serviços AWS e ferramentas de terceiros, oferecendo flexibilidade para adaptar a solução às necessidades específicas de cada negócio.

Conclusão:

O Amazon Monitron representa uma solução inovadora e eficiente para o monitoramento preditivo de equipamentos industriais, especialmente aqueles com componentes rotativos, como motores e bombas. Sua capacidade de coletar dados em tempo real sobre vibração e temperatura, combinada com a aplicação de algoritmos de aprendizado de máquina, permite que empresas antecipem falhas e planejem manutenções de maneira proativa, reduzindo o tempo de inatividade e otimizando o desempenho operacional.

A facilidade de instalação e configuração, aliada às múltiplas possibilidades de integração com outros serviços da AWS, como o Kinesis Data Stream, Firehose, e AWS Athena, torna o Amazon Monitron uma ferramenta versátil e poderosa para uma ampla gama de aplicações industriais. Essas integrações possibilitam não apenas o armazenamento e análise de dados em tempo real, mas também a criação de soluções personalizadas de Business Intelligence, utilizando ferramentas como o Amazon QuickSight, para uma visualização clara e precisa dos dados.

Em resumo, o Amazon Monitron não apenas melhora a eficiência e a manutenção dos equipamentos, mas também oferece às empresas a oportunidade de transformar dados brutos em insights acionáveis, permitindo uma gestão mais inteligente e eficaz dos recursos industriais. A solução é ideal para organizações que buscam inovar e maximizar a produtividade, mantendo seus ativos em condições ideais de operação e minimizando interrupções inesperadas. Com sua abordagem abrangente e flexível, o Amazon Monitron se destaca como um recurso essencial para o futuro da manutenção industrial preditiva.

Bedrock - Conhecendo o recurso de Knowledge Bases

Gustavo Mainchein — Tue, 23 Jul 2024 11:57:38 +0000

Sobre o Recurso

Com as bases de conhecimento (Knowledge Bases) do Amazon Bedrock, você pode fornecer informações contextualizadas aos Modelos Fundacionais (FMs) e aos atendentes, extraídas de fontes de dados privadas da empresa. Isso permite que a Recuperação e Geração de Respostas (RAG) entregue respostas mais relevantes, precisas e personalizadas.

Na prática, o recurso de Knowledge Bases funciona integrado com um banco de vetores, como o OpenSearch, que armazena informações em um formato que facilita a busca e a comparação de distância entre os vetores de entrada e os armazenados. Quando um agente precisa responder a uma pergunta do usuário, ele consulta esse banco de vetores para encontrar informações relevantes. Essa consulta é feita através de busca semântica, um conjunto de recursos do mecanismo de busca que inclui a compreensão de palavras a partir da intenção e do contexto de quem está fazendo a busca. Isso permite que o agente identifique a informação privada que melhor corresponde à necessidade específica do usuário. Assim, o agente pode fornecer respostas mais precisas e relevantes, utilizando dados contextualizados e específicos da empresa.

Banco de Vetores

As informações que as empresas precisam armazenar, possuem diversos formatos. Algumas são não estruturadas, como documentos de texto, mídia avançada e áudio, enquanto outras são estruturadas, como logs de aplicações, tabelas e gráficos. Inovações em inteligência artificial e machine learning (IA/ML) nos permitiram criar um tipo de modelo de ML chamado modelos de incorporação. Incorporações codificam todos os tipos de dados em vetores que capturam o significado e o contexto de um ativo. Isso nos permite encontrar ativos semelhantes pesquisando pontos de dados vizinhos. Métodos de pesquisa de vetores possibilitam experiências exclusivas, como tirar uma fotografia com seu smartphone e pesquisar por imagens semelhantes.

Os bancos de dados de vetores oferecem a capacidade de armazenar e recuperar vetores como pontos de alta dimensão. Eles adicionam recursos para uma pesquisa rápida e eficiente dos vizinhos mais próximos no espaço N-dimensional. Em geral, são alimentados por índices k-Nearest Neighbor (k-NN) e construídos com algoritmos como Hierarchical Navigable Small World (HNSW) e Inverted File Index (IVF). Além disso, os bancos de dados de vetores fornecem funcionalidades adicionais, como gerenciamento de dados, tolerância a falhas, autenticação, controle de acesso e um mecanismo de consulta.

Vetorização na Prática

Para exemplificar o processo de vetorização de uma palavra, vamos utilizar como exemplo o seguinte texto: Inteligência Artificial.

Para transformar a palavra "Inteligência Artificial" em um vetor, utilizamos técnicas de embeddings, que convertem palavras em representações numéricas multidimensionais. Aqui está um exemplo de como isso é feito:

Tokenização: A frase "Inteligência Artificial" é dividida em tokens, geralmente palavras ou sub-palavras. Neste caso, temos "Inteligência" e "Artificial".
Embedding: Cada token é então convertido em um vetor usando um modelo de embedding pré-treinado, como Word2Vec, GloVe, BERT, etc. Estes vetores são de alta dimensão e capturam o significado semântico das palavras.

Por exemplo, utilizando um modelo como Word2Vec, a palavra "Inteligência" pode ser representada por um vetor de 300 dimensões:

[0.15, -0.23, 0.45, ..., 0.33]

E "Artificial" por outro vetor de 300 dimensões:

[-0.12, 0.29, -0.34, ..., 0.18]

Combinação de Vetores: Se desejarmos representar a frase inteira "Inteligência Artificial" como um único vetor, podemos combinar os vetores das palavras individuais. Uma abordagem comum é calcular a média dos vetores:

"Inteligência Artificial" = media([0.15, -0.23, 0.45, ..., 0.33], [-0.12, 0.29, -0.34, ..., 0.18])

Vetor Final: O vetor resultante da média ou combinação das palavras individuais representa a frase inteira no espaço vetorial:

[0.015, 0.03, 0.055, ..., 0.255]

Esse vetor capturará a semântica da frase "Inteligência Artificial" e poderá ser utilizado em várias aplicações de IA/ML, como busca semântica, classificação de texto, etc.

Knowledge Bases na Prática

Pensando no contexto acima, vamos para a parte prática de criação e publicação de um exemplo do recurso de Knowledge Bases.

1º Passo: Criação do bucket S3 que será utilizado para armazenar os dados não estruturados:

Observação: O Knowledge Bases possui formatos específicos que consegue vetorizar. Qualquer documento que não esteja dentro de seu formato aceito, será necessário criar uma camada de aplicação para realizar a conversão em um dos formatos aceitos. Os formatos de arquivos suportados pelo Knowledge Bases são:

Plain text	.txt
Markdown	.md
HyperText Markup Language	.html
Microsoft Word document	.doc/.docx
Comma-separated values	.csv
Microsoft Excel spreadsheet	.xls/.xlsx
Portable Document	.pdf

2º Passo: Acesso ao serviço do Bedrock e seleção do menu de Builder tools > Knowledge Bases:

3º Passo: Preencha os campos padrões da primeira tela da forma como preferir e, na segunda tela, selecione o bucket criado no 1º passo:

4º Passo: Selecione o modelo de sua preferência para fazer o processo de embeddings (explicado anteriormente) dos documentos inseridos no bucket e deixe a opção de “Quick create a new vector store - Recommended” selecionada para criação do OpenSearch como banco de vetores:

1ª Observação: Caso você já possua um banco de vetores, selecione a opção “Choose a vector store you have created” e preencha as informações do seu banco atual;
2ª Observação: Para ambientes produtivos é recomendado que você ative as opções de redundância e criptografias abaixo da seleção do “Vector database”.

5º Passo: Após executar os passos acima, seu recurso de Knowledge Bases estará criado e irá faltar apenas executar o “Sync” dos documentos presentes em seu “Data Source”:

Conclusão

O recurso de Knowledge Bases do Amazon Bedrock proporciona uma maneira poderosa e eficiente de integrar informações contextuais em sistemas de atendimento e Modelos Fundacionais (FMs). Ao utilizar bancos de vetores, como o OpenSearch, para armazenar e recuperar dados em formatos estruturados e não estruturados, a busca semântica é potencializada, permitindo que agentes encontrem as informações mais relevantes de forma rápida e precisa. Através de técnicas de embeddings, esses dados são convertidos em vetores que capturam significado e contexto, facilitando a comparação e a recuperação de informações semelhantes. Essa abordagem inovadora não só melhora a precisão das respostas fornecidas aos usuários, mas também possibilita novas experiências de pesquisa e interação com dados. Com um processo claro de criação, configuração e sincronização de dados, as empresas podem aproveitar ao máximo as capacidades das Knowledge Bases para otimizar seus fluxos de trabalho e proporcionar um atendimento mais personalizado e eficiente.

AWS IoT Core - Integração

Gustavo Mainchein — Tue, 19 Mar 2024 11:27:37 +0000

Introdução

Neste guia, exploraremos a integração de dispositivos com o serviço AWS IoT Core utilizando Node.js como uma "thing” que irá enviar dados e também uma stack de data stream para processá-los, com Kinesis (Data Stream e Firehose) + S3. Pensando nesse cenário, começaremos a abordar e entender o serviço de IoT Core da AWS.

A sigla IoT significa Internet das Coisas (em inglês, Internet of Things) e se refere à rede de objetos físicos que são conectados à internet e podem coletar / trocar dados. Essa conexão permite que os objetos sejam monitorados e controlados remotamente, abrindo um mundo de possibilidades para diversas áreas.

Como funciona o IoT?

O funcionamento da IoT pode ser dividido em quatro etapas principais:

1. Coleta de dados: Sensores (equipamentos como Arduíno, MTJ e outros) presentes nos objetos físicos coletam dados sobre o ambiente em que estão inseridos. Esses dados podem ser, como por exemplo, temperatura, umidade, localização, movimento, entre outros.

2. Transmissão de dados: Os dados coletados são então transmitidos para a nuvem através de uma conexão Wi-Fi, Bluetooth, celular ou via satélite. Geralmente, é muito comum encontrarmos transmissão via Wi-Fi e/ou Bluetooth.

3. Armazenamento de dados: Na nuvem, os dados são processados, por recursos exclusivos que conseguem entender as conexões que utiliza, como MQTT e HTTPS, e armazenados em storages, de forma particinada, para uma análise / tomada de ação futura.

4. Análise e uso dos dados: Os dados armazenados são analisados e podem ser utilizados para diversas finalidades.

O que é o AWS IoT Core?

O AWS IoT Core é um serviço integralmente gerenciado pela AWS, criado para simplificar e fortalecer as operações relacionadas à Internet das Coisas (IoT) em escala massiva. Sua utilização está fundamentada em 3 principais pilares:

Conectividade Avançada: O AWS IoT Core é projetado para suportar múltiplos protocolos de comunicação, incluindo MQTT (Message Queuing Telemetry Transport), HTTP (Hypertext Transfer Protocol) e WebSockets. Essa capacidade é crucial para garantir a interoperabilidade e a flexibilidade necessárias em ambientes IoT complexos e heterogêneos.
Gerenciamento Abrangente: O serviço oferece ferramentas e funcionalidades para simplificar e automatizar o gerenciamento de dispositivos IoT em larga escala. Além disso, o AWS IoT Core oferece recursos avançados de monitoramento e diagnóstico, permitindo que os operadores identifiquem e resolvam problemas de forma proativa, minimizando interrupções no fluxo de dados e maximizando a eficiência operacional.
Segurança Robusta: Em um cenário onde a segurança dos dispositivos IoT e dos dados transmitidos é uma preocupação constante, o AWS IoT Core oferece um conjunto abrangente de recursos para proteger a integridade e a confidencialidade das operações IoT. Isso inclui mecanismos avançados de autenticação e autorização, garantindo que apenas dispositivos autorizados tenham acesso aos recursos da nuvem IoT. Além disso, o serviço utiliza técnicas de criptografia para proteger a comunicação entre dispositivos e a nuvem.

Casos de Uso do AWS IoT Core

O AWS IoT Core pode ser utilizado em diversos casos de uso, como:

Monitoramento ambiental: Coleta de dados de sensores para monitorar temperatura, umidade, qualidade do ar etc.
Automação residencial: Controle de dispositivos domésticos inteligentes, como lâmpadas, termostatos e eletrodomésticos.
Rastreamento de ativos: Monitoramento da localização e do status de ativos em tempo real.
Manutenção preditiva: Análise de dados de sensores para prever falhas de equipamentos e realizar manutenções preventivas.

Integração de Dispositivos com Node.js

O Node.js é uma plataforma ideal para desenvolver aplicações de IoT devido à sua natureza leve, escalável e assíncrona. A integração de dispositivos com o AWS IoT Core utilizando Node.js pode ser realizada através do seguinte processo:

a. Instalar as bibliotecas necessárias:

mqtt: Biblioteca para comunicação com o protocolo MQTT.
fs: Biblioteca para interpretação dos arquivos de certificados que a aplicação irá utilizar para realizar a comunicação com as things do IoT Core.

b. Criar um cliente Node.js:

O cliente Node.js é responsável por se conectar ao AWS IoT Core, publicar e receber mensagens. Trata-se de uma aplicação Node.js que irá embarcada nos “sensores”, que são os equipamentos que coletam dados, como por exemplo um Arduíno, MTJ e/ou outros.

c. Configurar o cliente com os dados de conexão do IoT Core:

Endpoint do broker MQTT: Endereço do broker MQTT do AWS IoT Core, localizado na aba de "Connect” > "Connect one device” do serviço.
Credenciais do dispositivo: Chave privada e certificado do dispositivo, geradas no momento da criação de um certificado ou de uma thing.
Tópico MQTT: Tópico utilizado para comunicação entre o dispositivo e o AWS IoT Core, configurado na aba de "Message routing” > "Rules”.

d. Conectar o cliente ao AWS IoT Core:

O cliente Node.js se conecta ao broker MQTT utilizando as credenciais do dispositivo, publicar mensagens no tópico MQTT configurado e receber mensagens de outros dispositivos que estão inscritos no mesmo tópico MQTT.

Protocolos Envolvidos na Integração

Para uma integração de dispositivos com o AWS IoT Core usando Node.js, é essencial entender os principais protocolos envolvidos. Aqui estão alguns deles:

MQTT (Message Queuing Telemetry Transport): O MQTT é um protocolo leve e altamente eficiente projetado para facilitar a comunicação em tempo real entre dispositivos IoT e a nuvem. Ele é particularmente adequado para ambientes onde largura de banda e recursos computacionais são limitados, pois minimiza a sobrecarga de rede e oferece uma troca de mensagens assíncrona e confiável.
HTTPS (Hypertext Transfer Protocol Secure): O HTTPS é um protocolo amplamente utilizado para comunicação segura entre clientes web e servidores. No contexto da integração de dispositivos com o AWS IoT Core usando Node.js, o HTTPS é empregado como uma camada adicional de segurança para proteger a comunicação entre o cliente Node.js e a plataforma AWS IoT Core. Ao utilizar HTTPS, todas as comunicações são criptografadas, garantindo a confidencialidade e a integridade dos dados transmitidos. Isso é especialmente importante em cenários onde a segurança é uma prioridade, como na transmissão de dados sensíveis ou na execução de operações críticas.

Arquitetura Envolvida na Integração

Pensando nos tópicos documentados acima, temos a seguinte arquitetura que é muito comum de ser utilizada quando nos tratamos de um projeto que envolva IoT, pois é capaz de processar uma massa gigantesca de dados do seu dispositivo:

Sobre a arquitetura acima, temos:

Os dispositivos IoT (Arduíno rodando uma aplicação Node.js) enviam dados para o IoT Core usando o protocolo MQTT, que é leve e altamente eficiente quando precisamos enviar grande quantidade de dados.
O IoT Core roteia os dados para o Kinesis Data Streams.
O Kinesis Data Streams processa os dados em tempo real e os envia para o Kinesis Firehose.
O Kinesis Firehose transforma os dados e os armazena no S3, de forma particionada entre /ano/mes/dia/hora.

Script para Envio de Dados ao IoT Core

Pensando no script para conexão MQTT e envio de dados ao IoT Core da AWS, temos:

1. Importação de Bibliotecas:

mqtt: Utilizada para comunicação com o protocolo MQTT, padrão na comunicação com a Internet das Coisas (IoT).
fs: Fornece funções para interagir com o sistema de arquivos, permitindo a leitura de arquivos de configuração e certificados.
dotenv: Permite carregar variáveis de ambiente a partir de um arquivo .env, facilitando a configuração sem a necessidade de expor dados sensíveis no código.

2. Configuração de Variáveis:

iotMqttEndpoint: URL do endpoint MQTT do serviço AWS IoT Core, composto pelo endpoint da região, porta e protocolo seguro (mqtts).
iotKeyFile, iotCertFile, iotCaFile: Caminhos para os arquivos de chave privada, certificado e CA (Autoridade Certificadora) necessários para autenticação no AWS IoT Core.
iotTopic: Nome do tópico MQTT para troca de mensagens.
message: Mensagem a ser publicada no tópico MQTT, contendo o tipo da mensagem ("String") e os dados ("Send message with successfully!"), junto com um timestamp.

3. Conexão ao AWS IoT Core:

Cria um cliente MQTT usando a biblioteca mqtt e a URL do endpoint configurado.
Fornece as credenciais (chave, certificado e CA) para autenticação.
Especifica o protocolo MQTT e a versão 5.

4. Eventos do Cliente:

connect: Ao conectar-se com sucesso, o cliente se inscreve no tópico MQTT. Em caso de falha na inscrição, um erro é registrado.
subscribe: Ao inscrever-se no tópico com sucesso, uma mensagem é publicada nesse tópico.
message: Ao receber uma mensagem no tópico, o conteúdo da mensagem é exibido no console.
error: Se ocorrer algum erro durante a comunicação com o AWS IoT Core, o erro é registrado no console.

O script estabelece uma conexão segura com o AWS IoT Core utilizando o protocolo MQTT. Ele se inscreve em um tópico específico e publica uma mensagem nesse tópico. Também é capaz de receber mensagens publicadas por outros dispositivos ou aplicações no mesmo tópico. Esse tipo de script é comum na comunicação com dispositivos IoT e na interação com serviços de nuvem relacionados à Internet das Coisas.

Acesse o respositório do link ao lado, baixe e crie o seu: https://github.com/gugamainchein/aws-iot-core-publish-messages

Considerações Finais

Neste guia, exploramos a integração de dispositivos com o serviço AWS IoT Core utilizando Node.js. Abordamos os principais tópicos, como:

O que é IoT e como funciona;
O que é o AWS IoT Core e seus casos de uso;
Como integrar dispositivos com Node.js;
Os protocolos envolvidos (MQTT e HTTPS);
Arquitetura para processamento de dados (Kinesis, Firehose e S3);
Script para envio de dados ao IoT Core.

Fornecemos um resumo detalhado do funcionamento, dos componentes e da comunicação entre eles na arquitetura proposta. Também destacamos as vantagens e aplicações da integração com o AWS IoT Core.

Para aprofundar seus conhecimentos, acesse o repositório com o script completo: https://github.com/gugamainchein/aws-iot-core-publish-messages.

Este guia serve como base sólida para iniciar o desenvolvimento de suas aplicações de IoT utilizando Node.js e o AWS IoT Core.