DEV Community: Bryan Doss

Introducing muxtree: Dead-Simple Worktree + Tmux Sessions for AI Coding

Bryan Doss — Wed, 18 Feb 2026 23:20:53 +0000

There are already tools for managing parallel AI coding sessions. The Codex app handles it natively, and projects like Conductor give you orchestration across agents. They're great, but they're opinionated about how you work and over engineered for what I need.

I wanted something dumber. Something that just sets up the workspace and gets out of the way.

I built muxtree; a single bash script that pairs git worktrees with tmux sessions. You pick which agent runs where, you switch between them freely, and everything uses the Claude Code or Codex CLI you already have installed on your machine. No wrappers, no abstractions over the agent itself.

One command

muxtree new feature-auth --run claude

You get:

A git worktree branched from main
Your .env, CLAUDE.md, etc. copied over
A tmux session with two windows — dev and agent — with Claude Code already running in the agent window
A terminal window attached to the session

Switch between windows with Ctrl-b n / Ctrl-b p. That's the whole interface.

Why tmux

Because you need to check on your agent, glance at your dev server, then jump back. Tmux windows make that instant. And because tmux sessions persist, close your terminal, come back later, everything's still running. Most importantly, I’ve started SSH-ing into my work computer from my phone and tmux means I can easily pick up where I left off.

muxtree sessions close fix-bug           # walk away
muxtree sessions open fix-bug --run claude  # pick up where you left off

Run different agents on different tasks

muxtree new feature-auth --run claude
muxtree new fix-bug --run codex
muxtree list                             # see everything at a glance

No lock-in. Use whatever CLI is on your $PATH. You don't even have to use agentic coding to make use of it.

Setup

cp muxtree /usr/local/bin/muxtree && chmod +x /usr/local/bin/muxtree
muxtree init

Three questions: where to put worktrees, which terminal app, which files to copy. Done. Tab completion for bash and zsh included.

No dependencies beyond git and tmux. No package manager. One bash script, MIT licensed.

GitHub: https://github.com/b-d055/muxtree

Your JSON Schema Is a Prompt - Tips for AWS Bedrock Structured Output

Bryan Doss — Sun, 15 Feb 2026 17:07:53 +0000

The JSON schema you pass to an LLM isn't just a structural contract. It's a prompt that directly controls output quality. Field names, descriptions, ordering, and enum values all steer the model's behavior just like your system prompt does. Get them right and you'll get reliably excellent outputs. Get them wrong and you'll get structurally valid garbage.

AWS Bedrock just shipped constrained decoding that guarantees your responses match a JSON schema. But guaranteed structure doesn't mean guaranteed quality. This post is about the second half of that equation: how to design schemas that produce the right data, not just the right shape.

Full runnable examples can be found in the accompanying GitHub repo.

The 30-second version of how Bedrock enforces schemas

When you submit a JSON schema to Bedrock's API:

Bedrock validates your schema against JSON Schema Draft 2020-12
On first use, it compiles the schema into a grammar (can take up to a few minutes)
The compiled grammar is cached for 24 hours per account
During generation, invalid tokens are masked out so the model literally cannot produce output that violates the schema

This isn't "generate then validate." The model is physically prevented from producing wrong-typed values, missing fields, or malformed JSON. Here's the basic API call:

import boto3, json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "sentiment": {"type": "string", "enum": ["positive", "negative", "neutral"]},
    },
    "required": ["name", "sentiment"],
    "additionalProperties": False,  # MANDATORY on every object
}

response = bedrock.converse(
    modelId="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{
        "role": "user",
        "content": [{"text": "Analyze: 'I love this product!' - Sarah"}],
    }],
    inferenceConfig={"maxTokens": 256},
    outputConfig={
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(schema),
                    "name": "sentiment_analysis",
                }
            },
        }
    },
)

data = json.loads(response["output"]["message"]["content"][0]["text"])
# {"name": "Sarah", "sentiment": "positive"} - guaranteed.

That's your foundation. Now let's talk about what makes the schema itself good or bad.

Tip 1: Field names are implicit instructions

LLMs generate tokens one at a time. When the model writes "customer_full_name":, that string becomes context that influences the next token. The model has been trained on billions of lines of code and docs. It knows what customer_full_name expects. It has no idea what cust_nm means. As AWS's docs put it: clear names like customer_email outperform generic names like field1.

Bad schema:

schema = {
    "type": "object",
    "properties": {
        "nm": {"type": "string"},
        "val": {"type": "number"},
        "cat": {"type": "string"},
    },
    "required": ["nm", "val", "cat"],
    "additionalProperties": False,
}
# Model output: {"nm": "Widget A", "val": 3, "cat": "B"}
# What does val mean? What's cat? The model is guessing too.

Good schema:

schema = {
    "type": "object",
    "properties": {
        "product_name": {"type": "string"},
        "rating_out_of_five": {"type": "number"},
        "product_category": {
            "type": "string",
            "enum": ["electronics", "clothing", "food", "home", "other"],
        },
    },
    "required": ["product_name", "rating_out_of_five", "product_category"],
    "additionalProperties": False,
}
# Model output: {"product_name": "Widget A", "rating_out_of_five": 4.2, "product_category": "electronics"}
# Every field is self-explanatory. The model knows exactly what to produce.

Same tokens, same price, dramatically better results.

Tip 2: Descriptions are micro-prompts

Schema description fields aren't just for humans. They're sent to the model as input context and function as inline instructions. The PARSE research system demonstrated that optimizing field descriptions (with other optimizations) achieved up to 64.7% improvement in extraction accuracy.

Here's a real-world example: extracting support tickets from emails:

schema = {
    "type": "object",
    "properties": {
        "customer_name": {
            "type": "string",
            "description": "Full name of the person who sent the email",
        },
        "issue_summary": {
            "type": "string",
            "description": "One-sentence summary of the problem, max 20 words",
        },
        "severity": {
            "type": "string",
            "enum": ["low", "medium", "high", "critical"],
            "description": "low=cosmetic, medium=degraded, high=broken, critical=data loss or outage",
        },
        "product_area": {
            "type": "string",
            "enum": ["billing", "api", "dashboard", "auth", "other"],
            "description": "Which product area the issue relates to. Use 'other' if unclear.",
        },
        "requires_followup": {
            "type": "boolean",
            "description": "True if the customer asked a direct question or requested a callback",
        },
    },
    "required": ["customer_name", "issue_summary", "severity", "product_area", "requires_followup"],
    "additionalProperties": False,
}

Notice how the severity description encodes business logic: what "high" means in your org's terms. Without it, the model guesses. With it, the model follows your definitions.

The issue_summary description includes a soft length constraint. Bedrock's grammar engine can't enforce word counts (no maxLength), but the model will follow it as an instruction.

Pro tip: changing descriptions doesn't invalidate Bedrock's grammar cache. You can iterate on wording to improve quality without triggering recompilation.

Tip 3: Field order controls reasoning quality

I think this is the most under appreciated principle. LLMs generate fields sequentially, so the order they appear determines the order the model thinks about them. Put an answer before the reasoning and the model commits before it thinks. Dylan Castillo demonstrated with statistical significance (p < 0.01) that placing reasoning fields before answer fields produces substantially better results.

Bad: answer first, reasoning after:

# ❌ Don't do this
schema = {
    "type": "object",
    "properties": {
        "is_fraudulent": {"type": "boolean"},
        "confidence": {"type": "number"},
        "reasoning": {"type": "string"},
    },
    "required": ["is_fraudulent", "confidence", "reasoning"],
    "additionalProperties": False,
}
# Model decides is_fraudulent BEFORE it reasons.
# The reasoning becomes post-hoc justification.

Good: reasoning first, then conclusion:

# ✅ Do this instead
fraud_schema = {
    "type": "object",
    "properties": {
        "risk_indicators": {
            "type": "array",
            "items": {"type": "string"},
            "description": "Suspicious patterns observed in the transaction",
        },
        "analysis": {
            "type": "string",
            "description": "Step-by-step reasoning about whether this is fraudulent",
        },
        "is_fraudulent": {
            "type": "boolean",
            "description": "Final determination based on the analysis above",
        },
        "confidence": {
            "type": "number",
            "description": "Confidence between 0.0 and 1.0",
        },
    },
    "required": ["risk_indicators", "analysis", "is_fraudulent", "confidence"],
    "additionalProperties": False,
}

Now the model identifies indicators, reasons through them, then decides. It's the single biggest quality lever in schema design.

Here's that fraud detector wired up to Bedrock:

transaction = """
Transaction: $4,299 at "ELCTRNX STORE" on 2026-02-14 at 3:47 AM
Card ending: 8842, Location: Lagos, Nigeria
Cardholder home: Portland, Oregon
Previous transactions: Average $85, all within Oregon
"""

response = bedrock.converse(
    modelId="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{
        "role": "user",
        "content": [{"text": f"Analyze this transaction for fraud:\n{transaction}"}],
    }],
    inferenceConfig={"maxTokens": 1024},
    outputConfig={
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(fraud_schema),
                    "name": "fraud_analysis",
                }
            },
        }
    },
)

result = json.loads(response["output"]["message"]["content"][0]["text"])
if result["is_fraudulent"] and result["confidence"] > 0.8:
    block_transaction(result)

Tip 4: Enums do two jobs at once

Enums constrain outputs mechanically (the model can't produce tokens outside the set) and semantically (they tell the model what categories exist). No other schema feature does both. The AWS Bedrock ML blog recommends using enums whenever possible to improve accuracy.

Without enums:

{"sentiment": {"type": "string"}}
# You'll get: "positive", "Positive", "POSITIVE", "good",
# "mostly positive", "👍"... good luck with downstream logic.

With enums:

{"sentiment": {"type": "string", "enum": ["positive", "negative", "neutral", "mixed"]}}
# Exactly one of those four values. Every. Single. Time.

Three design rules: use human-readable values ("positive" not "pos"), always include a fallback ("other" or "unknown"), and define meanings in descriptions.

Here's a full runnable example: structured code review:

code_review_schema = {
    "type": "object",
    "properties": {
        "issues": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "line_range": {
                        "type": "string",
                        "description": "e.g. '12-15' or '42'",
                    },
                    "severity": {
                        "type": "string",
                        "enum": ["critical", "warning", "suggestion", "nitpick"],
                        "description": "critical=bugs/security, warning=likely problems, suggestion=improvements, nitpick=style only",
                    },
                    "category": {
                        "type": "string",
                        "enum": ["security", "performance", "correctness", "readability", "other"],
                    },
                    "what": {"type": "string", "description": "What the issue is and why it matters"},
                    "fix": {"type": "string", "description": "Concrete code or approach to fix it"},
                },
                "required": ["line_range", "severity", "category", "what", "fix"],
                "additionalProperties": False,
            },
        },
        "overall_quality": {
            "type": "string",
            "enum": ["excellent", "good", "needs_work", "poor"],
        },
        "summary": {"type": "string", "description": "2-3 sentence overall assessment"},
    },
    "required": ["issues", "overall_quality", "summary"],
    "additionalProperties": False,
}

code_snippet = '''
def process_payment(card_number, amount):
    query = f"INSERT INTO payments VALUES ('{card_number}', {amount})"
    db.execute(query)
    return True
'''

response = bedrock.converse(
    modelId="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{
        "role": "user",
        "content": [{"text": f"Review this Python code:\n```
{% endraw %}
python\n{code_snippet}\n
{% raw %}
```"}],
    }],
    inferenceConfig={"maxTokens": 1024},
    outputConfig={
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(code_review_schema),
                    "name": "code_review",
                }
            },
        }
    },
)

review = json.loads(response["output"]["message"]["content"][0]["text"])
critical = [i for i in review["issues"] if i["severity"] == "critical"]
print(f"Found {len(critical)} critical issues")
for issue in critical:
    print(f"  Line {issue['line_range']}: [{issue['category']}] {issue['what']}")

Tip 5: Handle missing data with nullable types

If a field is required but the source data doesn't contain that info, the model may hallucinate rather than leave it empty. When using Instructor, their library's prompting guide recommends nullable types and fallback values to prevent this.

# ❌ Forces hallucination when company isn't mentioned
{
    "company_name": {"type": "string"}
}

# ✅ Lets the model say "I don't know"
{
    "company_name": {
        "type": ["string", "null"],
        "description": "Company name if mentioned in the text, null otherwise"
    }
}

Keep it required (Bedrock wants this), but make the type nullable. The description reinforces when null is appropriate.

Putting it all together: job posting extractor

Here's a complete pipeline combining every tip: reasoning first, descriptive names, rich descriptions, enums with fallbacks, and nullable types for missing data:

import boto3, json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

job_schema = {
    "type": "object",
    "properties": {
        # REASONING FIRST: let the model observe before concluding
        "observations": {
            "type": "string",
            "description": "Key details noticed: compensation, requirements, red flags, remote policy",
        },
        # THEN structured extraction with descriptive names
        "job_title": {"type": "string", "description": "Exact job title as listed"},
        "company_name": {"type": "string"},
        "location": {
            "type": "object",
            "properties": {
                "city": {"type": ["string", "null"]},
                "state_or_country": {"type": ["string", "null"]},
                "remote_policy": {
                    "type": "string",
                    "enum": ["fully_remote", "hybrid", "on_site", "not_specified"],
                },
            },
            "required": ["city", "state_or_country", "remote_policy"],
            "additionalProperties": False,
        },
        "salary": {
            "type": "object",
            "properties": {
                "min_usd": {"type": ["integer", "null"], "description": "Min salary in USD, null if not listed"},
                "max_usd": {"type": ["integer", "null"], "description": "Max salary in USD, null if not listed"},
                "period": {
                    "type": "string",
                    "enum": ["annual", "monthly", "hourly", "not_specified"],
                },
            },
            "required": ["min_usd", "max_usd", "period"],
            "additionalProperties": False,
        },
        "experience_level": {
            "type": "string",
            "enum": ["intern", "entry", "mid", "senior", "staff", "principal", "executive", "not_specified"],
            "description": "Infer from title and requirements if not explicitly stated",
        },
        "required_skills": {
            "type": "array",
            "items": {"type": "string"},
            "description": "Skills explicitly listed as required (not nice-to-have)",
        },
        "nice_to_have_skills": {
            "type": "array",
            "items": {"type": "string"},
            "description": "Skills listed as preferred or bonus",
        },
        # CONCLUSIONS LAST
        "is_legitimate": {
            "type": "boolean",
            "description": "False if the posting shows scam signs (vague company, unrealistic pay)",
        },
    },
    "required": [
        "observations", "job_title", "company_name", "location",
        "salary", "experience_level", "required_skills",
        "nice_to_have_skills", "is_legitimate",
    ],
    "additionalProperties": False,
}

posting = """
Senior Backend Engineer - FinTech Startup (Series B)
Location: San Francisco, CA (Hybrid - 3 days/week)
Salary: $185,000 - $220,000 + equity

We're building the future of real-time payments. You'll own services
handling 50M+ transactions/day in Go on Kubernetes + PostgreSQL.

Must have: 5+ years backend, strong Go, distributed systems experience.
Bonus: payments industry experience, Rust.
"""

response = bedrock.converse(
    modelId="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{
        "role": "user",
        "content": [{"text": f"Extract job posting data:\n\n{posting}"}],
    }],
    inferenceConfig={"maxTokens": 1024},
    outputConfig={
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(job_schema),
                    "name": "job_extraction",
                }
            },
        }
    },
)

job = json.loads(response["output"]["message"]["content"][0]["text"])

print(f"{job['job_title']} at {job['company_name']}")
print(f"  Location: {job['location']['city']}, {job['location']['state_or_country']} ({job['location']['remote_policy']})")
if job['salary']['min_usd']:
    print(f"  Salary: ${job['salary']['min_usd']:,} - ${job['salary']['max_usd']:,} {job['salary']['period']}")
print(f"  Level: {job['experience_level']}")
print(f"  Required: {', '.join(job['required_skills'])}")
print(f"  Nice to have: {', '.join(job['nice_to_have_skills'])}")
print(f"  Legit: {'Yes' if job['is_legitimate'] else 'SUSPICIOUS'}")

Three things that will still break you

Token limit truncation. If maxTokens is too low, the JSON gets cut off mid-structure. Check stopReason. If it's "max_tokens", your output is probably malformed. Set it generously.
Safety refusals. If the model declines for policy reasons, you'll get a non-conforming response.
Structurally valid but semantically wrong. Constrained decoding guarantees the shape. It does NOT guarantee the content. A well-designed schema is your best defense, but validate business-critical outputs.

TL;DR

Your JSON schema is a prompt. Treat it like one.

Name fields descriptively: customer_full_name not cust_nm
Write descriptions: they're instructions the model follows
Order fields: reasoning first, conclusions last. Biggest quality lever
Use enums with fallbacks: mechanical + semantic constraint in one
Make absent data nullable: don't force hallucination
Keep schemas flat: deep nesting increases latency and errors
Set additionalProperties: false: Bedrock requires it everywhere
Set maxTokens high enough: truncation breaks everything

The schema is the prompt. Design it accordingly.

See accompanying GitHub repo for runnable code examples.

You can find me on LinkedIn | CTO & Partner @ EES.

Vectorless Rag with AWS Bedrock and PageIndex

Bryan Doss — Wed, 28 Jan 2026 02:22:59 +0000

PageIndex caught my eye when it hit GitHub's trending page. It's a RAG framework that ditches vectors in favor of document structure and human-like LLM reasoning. I had to try it.

The open-source version is pretty bare-bones. It handles tree generation fine, but if you want to actually query your documents locally, you're on your own. So I forked it, added the missing retrieval pieces, and threw in AWS Bedrock support while I was at it.

This post walks through how to run the full PageIndex pipeline locally with Bedrock as your (retrieval) LLM provider.

Full code: github.com/b-d055/PageIndex
(Clone the repo and run local_rag.py with examples provided to get started right away)

What is PageIndex?

Traditional vector-based RAG relies heavily on semantic similarity as a proxy for relevance. While this works well for many use cases, it often breaks down with long, structured, or highly technical documents that require domain knowledge and multi-step reasoning. In those cases, retrieving text that merely “sounds similar” to a query isn’t enough. PageIndex takes a different approach by using LLM reasoning to navigate a document’s structure, prioritizing sections based on how a human expert would actually search for an answer.

For a deeper dive into the motivation and design, check out PageIndex's introductory blog post.

PageIndex mimics how a human expert navigates documents:

Read the structure - Parse the document's hierarchy (like a table of contents) to understand what's where
Reason over sections - Use LLM reasoning to identify which sections likely contain relevant information
Extract and evaluate - Pull content from selected sections and assess if it's sufficient to answer the query
Iterate or answer - If more context is needed, revisit the structure and select additional sections. Otherwise, generate the response.

The output is a hierarchical tree that mirrors how a human would navigate a document.

The Problem: Open Source vs API

The PageIndex GitHub repo provides tree generation, but the cookbooks all use their API (PageIndexClient) for RAG queries. It's free to start but may cost you depending on your features and usage. If you want to run everything locally or use your own LLM provider (like bedrock), you need to bridge this gap.

What the open-source repo includes:

run_pageindex.py - generates tree structures from PDFs
md_to_tree() - generates trees from Markdown
Utilities for PDF parsing, token counting, etc.

What's missing:

Query/retrieval functionality
Helper functions like create_node_mapping(), print_tree()
Support for non-OpenAI providers

Step 1: Generate a Tree Structure

First, generate a tree from your document. This step currently requires OpenAI. I may add alternative provider support in my fork later.

Add your OpenAI API key to a .env file:

OPENAI_API_KEY=your-key

Then run:

python run_pageindex.py --pdf_path document.pdf

Note: The upstream repo uses CHATGPT_API_KEY internally, but my fork accepts OPENAI_API_KEY and sets it automatically.

This creates a JSON file in results/ with:

Hierarchical sections extracted from the document
Page ranges for each section
AI-generated summaries
Full text content (requires --if-add-node-text yes)

Example tree structure:

{
  "doc_name": "quarterly-report.pdf",
  "structure": [
    {
      "title": "Financial Results",
      "start_index": 1,
      "end_index": 5,
      "node_id": "0001",
      "summary": "Overview of Q1 financial performance...",
      "text": "Full text content...",
      "nodes": [...]
    }
  ]
}

Important: The tree must include the text field for retrieval to work. Use --if-add-node-text yes during generation. It's off by default.

Step 2: Set Up AWS Bedrock

Generate a Bedrock API Key

AWS Bedrock now supports API key authentication. This simplifies setup significantly.

Go to the AWS Bedrock Console
Navigate to Model access and ensure you have access to Claude models (edit: model access page has been retired and is no longer required)
Go to API keys in the sidebar (you may need to scroll down)
Create a new API key (these can be short-term or long-term)
Copy the key. It's only shown once.

For more details, see the AWS documentation on Bedrock API keys.

Configure Environment

# .env
OPENAI_API_KEY=sk-...               # Required for tree generation
AWS_BEARER_TOKEN_BEDROCK=your-key   # For Bedrock queries
AWS_REGION=us-east-1                # Or your preferred region

How Authentication Works

boto3 automatically picks up the AWS_BEARER_TOKEN_BEDROCK environment variable:

import boto3
import os

os.environ['AWS_BEARER_TOKEN_BEDROCK'] = "your-api-key"

client = boto3.client('bedrock-runtime', region_name='us-east-1')
response = client.converse(modelId=model_id, messages=messages)

No IAM roles or AWS CLI configuration needed when using API key auth.

Step 3: Query with Bedrock

Now you can query your document using Bedrock:

python local_rag.py --provider bedrock \
    --model us.anthropic.claude-haiku-4-5-20251001-v1:0 \
    --tree results/document_structure.json \
    --query "What are the main conclusions?"

Or use interactive mode for multiple questions:

python local_rag.py --provider bedrock \
    --model us.anthropic.claude-haiku-4-5-20251001-v1:0 \
    --tree results/document_structure.json \
    -i

Some Bedrock Models to Try

Use the us. prefix for cross-region inference:

Model	ID
Claude Sonnet 4.5	`us.anthropic.claude-sonnet-4-5-20250929-v1:0`
Claude Haiku 4.5	`us.anthropic.claude-haiku-4-5-20251001-v1:0`
Amazon Nova Pro	`us.amazon.nova-pro-v1:0`
Amazon Nova Lite	`us.amazon.nova-lite-v1:0`

Tip: Claude Haiku 4.5 offers a good balance of speed and cost for RAG queries.

How the RAG Pipeline Works

The local RAG script implements a three-step pipeline:

1. Tree Search

Send the tree structure (without text) to the LLM and ask it to identify relevant nodes:

prompt = f"""
You are given a question and a tree structure of a document.
Find all nodes that are likely to contain the answer.

Question: {query}
Document tree structure: {tree_json}

Reply with: {{"thinking": "...", "node_list": ["0001", "0002"]}}
"""

2. Content Extraction

Retrieve the full text from the identified nodes:

for node_id in search_result['node_list']:
    context += node_map[node_id]['text']

3. Answer Generation

Send the extracted content to the LLM to generate an answer:

prompt = f"""
Answer the question based on the context:
Question: {query}
Context: {context}
"""

Key Implementation Details

Helper Functions

The open-source repo doesn't include these, so we implement them:

def create_node_mapping(tree_structure):
    """Create a flat mapping of node_id -> node for easy lookup."""
    node_map = {}

    def traverse(nodes):
        for node in nodes:
            if 'node_id' in node:
                node_map[node['node_id']] = node
            if 'nodes' in node:
                traverse(node['nodes'])

    traverse(tree_structure)
    return node_map

Bedrock Provider

class BedrockProvider:
    def __init__(self, model, region):
        self.client = boto3.client('bedrock-runtime', region_name=region)
        self.model = model

    def call(self, prompt):
        response = self.client.converse(
            modelId=self.model,
            messages=[{"role": "user", "content": [{"text": prompt}]}],
            inferenceConfig={"temperature": 0, "maxTokens": 4096}
        )
        return response['output']['message']['content'][0]['text']

Two-Phase Workflow

The key insight is separating tree generation from querying:

Phase	Provider	What Happens
Generation	OpenAI (required, for now)	Parse PDF, extract structure, generate summaries
Querying	Any (OpenAI/Bedrock)	Tree search, content extraction, answer generation

This means you can:

Generate the tree once
Query many times with any provider (use Haiku or Nova for speed)
Share tree files across team members

Files Reference

Notable files in my fork.

File	Purpose
`local_rag.py`	Main script with OpenAI + Bedrock support
`run_pageindex.py`	Tree generation from PDFs
`.env`	API keys (copy from `.env.example`)
`results/*.json`	Generated tree structures
`requirements.txt`	Dependencies including `boto3`

Conclusion

PageIndex is a refreshing take on RAG. Using document structure and reasoning instead of vector similarity can yield smarter retrieval. This is especially true for complex documents.

This implementation is intentionally simple. It's a starting point, not a production-ready system. The two-phase workflow (generate once, query many) keeps things practical. The tree structures are just human-readable JSON, so it's easy to inspect what's happening and build on top of it.

If you're tired of fighting with chunking strategies and embedding quality, give it a shot.

Resources

You can find me on LinkedIn | CTO & Partner @ EES.

AI-Ready Congressional Data: Building a Python Tool for Plaintext Extraction

Bryan Doss — Sat, 17 May 2025 15:41:56 +0000

Let's cut to the chase: Congressional Records are gold mines of political data, but they're trapped in PDFs and scattered across congress.gov. Yeah, there's an API, but it just gives you more PDFs or links to HTML pages. Not exactly AI-friendly.

I needed plaintext, I needed it in bulk, and I needed it yesterday. So I built a Python tool that:

Grabs data through the congress.gov API
Ignores those pesky PDFs
Extracts clean plaintext from the HTML pages
Organizes everything neatly

Why plaintext? Because you can actually do something with it! Search it, analyze it, feed it to AI models, cite specific sentences, or just read it without your eyes bleeding from PDF formatting.

Technical Implementation

The tool leverages several key strategies to efficiently download records:

1. API Integration

The script uses the official congress.gov API, which requires an API key (free to obtain):

def fetch_issues(volume, api_key):
    url = f"https://api.congress.gov/v3/daily-congressional-record/{volume}?format=json&api_key={api_key}&limit=1000"
    retries = 10
    for i in range(retries):
        response = requests.get(url)
        if response.status_code == 200:
            return response.json().get("dailyCongressionalRecord", [])
        else:
            wait_time = 2 ** i
            print(f"Error: {response.status_code}, {response.text}. Retrying in {wait_time} seconds...")
            time.sleep(wait_time)
    print("Failed to fetch issues after multiple retries.")
    return []

2. Intelligent Rate Limiting

To handle API rate limits, the script implements exponential backoff (which is integrated directly in the API fetch functions as shown above).

3. Concurrent Processing

Downloads are accelerated using Python's concurrent.futures:

with concurrent.futures.ThreadPoolExecutor() as executor:
    futures = [executor.submit(fetch_and_compile_articles, args.volume, issue_number, args.api_key, args.force_override) 
               for issue_number in issue_numbers]
    for future in concurrent.futures.as_completed(futures):
        future.result()

4. Smart Text Extraction

The script handles congress.gov's HTML pages to extract clean plaintext:

def fetch_text_from_url(url):
    print(f"Fetching {url}...")
    retries = 10
    for i in range(retries):
        try:
            response = requests.get(url, timeout=30)
            if response.status_code == 200:
                soup = BeautifulSoup(response.text, 'html.parser')
                return soup.get_text()
            else:
                wait_time = 2 ** i
                print(f"Error: {response.status_code}. Retrying in {wait_time} seconds...")
                time.sleep(wait_time)
        except (requests.exceptions.Timeout, requests.exceptions.ConnectionError) as e:
            wait_time = 2 ** i
            print(f"Error: {e}. Retrying in {wait_time} seconds...")
            time.sleep(wait_time)
    print(f"Failed to fetch {url} after multiple retries.")
    return None

Instead of using the PDFs provided by the API, the tool navigates to the HTML URLs and extracts the text content directly. This gives us much cleaner text than we'd get from PDF extraction.

5. URL Extraction and Organization

The tool intelligently extracts the URLs for the HTML pages from the API response:

def extract_formatted_text_urls(data):
    urls = []
    if "articles" in data:
        for article in data["articles"]:
            for section in article.get("sectionArticles", []):
                for text_entry in section.get("text", []):
                    if text_entry.get("type") == "Formatted Text":
                        urls.append({
                            "url": text_entry.get("url"),
                            "startPage": section.get("startPage"),
                            "endPage": section.get("endPage")
                        })
    # Sort by startPage, then endPage
    urls.sort(key=lambda x: (x["startPage"], x["endPage"]))
    return [url["url"] for url in urls]

This makes sure we get all the text in a logical order, sorted by page number.

Example Usage

With the core functionality in place, using the tool is straightforward:

# Example usage
python get_congressional_record.py 170 your_api_key_here

The script handles everything: fetching issues, extracting articles, processing HTML, and saving the plaintext files in a structured directory format:

def fetch_and_compile_articles(volume, issue, api_key, force_override=False):
    print(f"Fetching articles for Volume {volume}, Issue {issue}...")
    directory = f'congressional_records_{volume}/issue_{issue}'
    os.makedirs(directory, exist_ok=True)

    data = fetch_articles(volume, issue, api_key)
    if data and data.get("articles"):
        urls = extract_formatted_text_urls(data)

        for url in urls:
            file_name = url.split('/')[-1].replace('.htm', '.txt')
            file_path = os.path.join(directory, file_name)

            # Check if the file already exists and if force_override is not set
            if os.path.exists(file_path) and not force_override:
                print(f"File {file_path} already exists. Skipping...")
                continue

            text_content = fetch_text_from_url(url)
            if text_content:
                with open(file_path, 'w') as f:
                    f.write(text_content)
                    f.write("\n\n")
    else:
        print("No articles")

With just one command, you can download an entire volume of Congressional Records in plaintext format, properly organized and ready for analysis.

This tool has already proven useful in real-world applications - I used it to help create a larger government data AI project described in my article Making Sense of Congressional Data with LightRAG, Amazon Bedrock and Ollama, where having clean plaintext was essential for effective AI processing.

Features and Benefits

Automatic Organization: Files are saved in a logical directory structure by volume and issue
Resume Capability: The --force-override flag lets you restart interrupted downloads
Error Resilience: Automatic retries handle temporary network issues
Minimal Dependencies: Only requires requests and beautifulsoup4
Plaintext Output: All records are saved as clean, structured text files

Example: Working with the Plaintext Data

Here's a simple example of how you might analyze the downloaded plaintext records:

import os
import glob
import re

def find_mentions(keyword, volume):
    mentions = []
    files = glob.glob(f"congressional_records_{volume}/**/*.txt", recursive=True)

    for file in files:
        with open(file, 'r', encoding='utf-8') as f:
            content = f.read()
            if re.search(r'\b' + re.escape(keyword) + r'\b', content, re.IGNORECASE):
                # Extract the paragraph containing the keyword
                paragraphs = content.split('\n\n')
                for para in paragraphs:
                    if re.search(r'\b' + re.escape(keyword) + r'\b', para, re.IGNORECASE):
                        mentions.append({
                            'text': para,
                            'source': f"Congressional Record Vol. {volume}, file: {file}",
                        })

    return mentions

# Example: Find all mentions of "climate change" in Volume 168
climate_mentions = find_mentions("climate change", 168)

Of course you can imagine how easy it would be to ingest this into a RAG pipeline.

Lessons Learned

Building this tool taught me several valuable lessons:

API Rate Limits are Your Friend: They prevent abuse and ensure fair access
Exponential Backoff Works: It's a simple but effective retry strategy
Direct Text Extraction is Superior: Accessing URLs for plaintext extraction yields cleaner results than the API's PDF options
Concurrency Speeds Things Up: But be mindful of rate limits

What's Next?

This tool opens up possibilities for further development:

Add support for specific date ranges or topics
Implement speaker identification to track who said what
Build citation generators for academic and journalistic use
Create a web interface for non-technical users
Develop text analysis tools specifically for Congressional discourse
Build APIs to serve this plaintext data to other applications

I'm already using the plaintext data from this tool in a larger government data AI project (see Making Sense of Congressional Data with LightRAG, Amazon Bedrock and Ollama), which demonstrates how this foundational data extraction work enables more sophisticated AI applications.

Conclusion

Government transparency shouldn't be limited by technical barriers or format issues. By automating Congressional Record downloads and converting them to plaintext, we make this valuable data more accessible and useful for everyone. Whether you're a researcher needing specific citations, a journalist fact-checking claims, a developer building civic tech, or an engaged citizen, having easy access to plaintext Congressional proceedings empowers better civic participation.

The complete source code is available on GitHub. Feel free to contribute, suggest features, or build upon this foundation.

Remember: democracy works best when information flows freely. Let's build tools that make that happen.

Have you built tools for accessing government data? What challenges did you face? Do you have ideas for how plaintext Congressional Records could be used? Let me know in the comments!

Making Sense of Congressional Data with LightRAG, Amazon Bedrock, and Ollama

Bryan Doss — Sat, 22 Mar 2025 21:14:51 +0000

Large language models (LLMs) are great, but sometimes they need a little help finding the right answer. Enter retrieval-augmented generation (RAG) systems and knowledge graphs. Today, I’m sharing how I used LightRAG with Amazon Bedrock and Ollama to build a knowledge graph from congressional records.

The result? A tool that makes it easier to sift through the details of legislative discussions and extract key information (or... just a fun excuse to tie together some of my recent favorite tools).

Full source code can be found in the GitHub repo.

What’s Cool About This Setup?

Amazon Bedrock gives you quick, affordable access to several foundation models (like the cost efficient amazon.nova-lite-v1:0) without the headache of managing GPUs or scaling issues.
Ollama helps generate embeddings locally—perfect for offline projects and keeping vendor-lock at bay (just remember, if you go fully offline, you’ll need a local LLM in place of Bedrock for prompt responses).
LightRAG a performant, lightweight alternative to Microsoft's GraphRAG to get starting with local graphs quickly.

What’s LightRAG?

LightRAG enhances RAG systems by integrating graph structures into text indexing and retrieval processes. In simple terms, it better connects related pieces of information, giving more accurate and quick answers. By combining graph relationships with vector-based retrieval, LightRAG pulls in context from both low-level details and high-level insights. An incremental update algorithm ensures your data stays fresh, making it a great choice when data is continuously evolving.

The Project Data

I used one day of congressional record data—a full transcript of legislative discussions. Using a knowledge graph here lets you ask meaningful questions like:

“What were the key legislative actions in this session?”
“Which topics dominated house debates?”

Getting Started

Prerequisites

An AWS account with Amazon Bedrock access
Ollama installed (download it here)
Python 3.10

1) Install Dependencies

Clone the repository from GitHub and run:

pip install -r requirements.txt

2) Configure AWS Credentials

Create a .env file with:

AWS_ACCESS_KEY_ID=<your-access-key-id>
AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
AWS_SESSION_TOKEN=""

3) Grant Access to Amazon Models

Follow the steps in the Amazon Bedrock documentation to request access to Amazon Foundation Models.

4) Pull the Embedding Model

Run:

ollama pull nomic-embed-text

Using The LightRAG CLI Wrapper

bedrock_graph.py is my CLI wrapper that operates in two modes:

Populate Mode

Load data into your knowledge graph.

For a directory:

python bedrock_graph.py --mode populate --working_dir ./cr_data --path ./cr_data_graph --llm_model_name amazon.nova-lite-v1:0

CLI Mode

Query your knowledge graph interactively:

python bedrock_graph.py --mode cli --working_dir ./cr_data_graph --llm_model_name amazon.nova-lite-v1:0

Example Query:

>> What were the key legislative actions for republicans?
... <response was here> ...
#### References
1. [KG] H.R. 2113 (File: ./cr_data/CREC-2025-03-14-pt1-PgH1158-3.txt)
2. [KG] H.R. 2115 (File: ./cr_data/CREC-2025-03-14-pt1-PgH1163-4.txt)
3. [KG] H.R. 2093 (File: ./cr_data/CREC-2025-03-14-pt1-PgH1162-3.txt)
4. [KG] H.R. 2145 (File: ./cr_data/CREC-2025-03-14-pt1-PgH1163-34.txt)
5. [KG] H.R. 2121 (File: ./cr_data/CREC-2025-03-14-pt1-PgH1163-10.txt)

One of the best things about LightRAG is its source citing capability.

A Quick Note on Customizing Bedrock Calls

By default, LightRAG's bedrock class uses anthropic.claude-3-haiku-20240307-v1:0. This is great if you're only analyzing a small amount of data - but I'll quickly rack up my AWS bill trying to analyze an entire year's worth of congressional records (stay tuned for the results of that project).

To adapt this for Amazons's cheaper foundation models, I needed to overwrite the bedrock_complete function as follows:

async def bedrock_complete(
    prompt, system_prompt=None, history_messages=[], keyword_extraction=False, **kwargs
) -> str:
    """
    Complete the prompt using Amazon Bedrock.
    Replacement for lightrag.llm.bedrock.bedrock_complete to use any Bedrock model.
    """
    keyword_extraction = kwargs.pop("keyword_extraction", None)
    llm_model_name = kwargs["hashing_kv"].global_config["llm_model_name"]
    kwargs.pop("stream", None)  # Bedrock doesn't support 'stream' kwarg
    result = await bedrock_complete_if_cache(
        llm_model_name,
        prompt,
        system_prompt=system_prompt,
        history_messages=history_messages,
        **kwargs,
    )
    if keyword_extraction:
        return locate_json_string_body_from_string(result)
    return result

This function is what I use when initializing LightRAG() instead of the built-in lightrag.llm.bedrock.bedrock_complete

Exploring the Graph

Once you have your knowledge graph populated, you can start exploring the data visually. This part is less useful but honestly much more fun to interact with for me. I generated some screenshots with the LightRAG API (find more info here) to show how data can be visualized.

I could seriously explore the relationships in this graph for hours...

You can also ask questions directly in the UI provided by the LightRAG API.

GraphML Export

One of the benefits of this setup is that the knowledge graph is stored in GraphML format. This makes it super easy to export, integrate, and query the data in other programs or databases. Whether you’re looking to analyze the graph with advanced graph tools or simply want to load it into a relational database for further use, GraphML provides a standardized, widely-supported way to do so.

<node id="U.S. Department of Commerce">
  <data key="de">U.S. Department of Commerce</data>
  <data key="d1">organization</data>
  <data key="d2">The U.S. Department of Commerce is a federal agency which</data>
  <data key="d3">chunk-e8c54b412ebbce72580d58073ce0497d&lt; SEP&gt;chunk</data>
</node>

Example node output in GraphML that will be in your ‘working_dir’

Note on Current Development

Keep in mind, LightRAG is still in development. You might notice some hallucinations in entity and relationship outputs - Nodes such as "Tokyo" and "World Athletics Championship" persist - even with larger models, these are artifacts of the one-shot examples in the system prompts. I have faith this will improve as the project evolves (or do it yourself with DSPy).

Wrapping Up

It's entirely possible to build knowledge graphs using LightRAG and Amazon Bedrock foundation models. Doing so greatly increases the accessibility and richness of the data for LLMs. Plus, by utilizing smaller models like Nova Lite, we can save a significant amount on token costs while preserving integrity.

Whether you're diving into congressional records or another data set, this approach shows promise in making data retrieval smarter, faster, and cheaper.

If you found this guide useful or have any questions, drop a comment below. Happy coding!

You can find me on LinkedIn | CTO & Partner @ EES.

De-identifying HIPAA PHI Using Local LLMs with Ollama

Bryan Doss — Sat, 15 Feb 2025 23:51:17 +0000

Recent advancements in smaller, more efficient language models have made it possible to run sophisticated NLP tasks entirely on consumer-grade hardware. Models like distiled DeepSeek-R1 (7/14B), Phi 4 (14B), and especially the new Mistral Small 3 (24B) can now perform complex tasks locally with impressive accuracy. This is a game-changer for sensitive data processing, as it eliminates the need for expensive cloud infrastructure or specialized hardware.

In this post, I'll show you how I used these local LLMs with Ollama to identify and remove Protected Health Information (PHI) from unstructured medical texts while maintaining data consistency - all running on standard desktop GPUs.

Example output of local LLM processing.

What is HIPAA PHI?

HIPAA (Health Insurance Portability and Accountability Act) defines 18 types of PHI that need to be removed or modified for data to be considered de-identified. This includes obvious identifiers like names and addresses, but also less obvious ones like device identifiers and biometric data.

Why Use Local LLMs?

While there are many cloud-based solutions for PHI de-identification, using local models has several advantages:

Data never leaves your environment
No API costs or rate limits
Faster processing with lower latency
Full control over the model and process

The best part? All of this runs on consumer-grade GPUs. I've successfully tested this solution on two NVIDIA RTX 3060s with 20GB of VRAM combined. However, you can run it on even older GPUs, given you have enough VRAM - or just run entirely on CPU with longer processing times.

The Solution: Ollama + Mistral

My solution uses Ollama running the Mistral Small 3 model locally to identify PHI elements. Here's how it works:

I create a detailed prompt that teaches the model about HIPAA PHI elements
Process the text in chunks to maintain context
Build a consistent mapping of PHI elements to replacement tokens
Replace the identified PHI with standardized tokens

The Core Components

Before trying to replicate, make sure you have Ollama installed and you've pulled Mistral Small 3 ollama pull mistral-small:24b.

Let's break down the key parts of the implementation:

Only relevant code blocks included below - see full code on GitHub.

1. First, I create a detailed prompt that specifies exactly what PHI elements to look for:

def create_hipaa_prompt() -> str:
    return f'''You are a HIPAA compliance expert. Analyze the text provided and identify all HIPAA Safe Harbor PHI elements including:
    - Names related to patient
    - Addresses or geographic subdivisions smaller than state
    - Dates (except years) and DOBs
    - Ages over 89
    [... other PHI elements ...]'''

2. I call Ollama's API to process the text:

def call_ollama(text: str, prompt: str, model: str = "mistral-small:24b"):
    full_prompt = f"{prompt}\n\nText to analyze:\n{text}"
    response = requests.post('http://localhost:11434/api/generate',
        json={
            "model": model,
            "options": {
                "temperature": 0.2,
            },
            "prompt": full_prompt,
            "stream": False
        }
    )
    ...

3. The model returns a JSON mapping of PHI elements to standardized tokens:

{
  "John A. Smith": "NAME_1",
  "123 Main St, Chicago": "ADDRESS_1",
  "09/28/1975": "DOB_1"
}

4. I maintain consistency by tracking used tokens and incrementing numbers as needed:

def deidentify_text(text: str, complete_phi_mappings: dict):
    phi_mappings = call_ollama(text, prompt)
    ...
    # De-duplicate the mappings
    keys_to_remove = [key for key in phi_mappings if key in complete_phi_mappings]
        for key in keys_to_remove:
            del phi_mappings[key]
    ...
    # Increment token variables if needed
    for key, value in phi_mappings.items():
            temp_value = value
            while temp_value in complete_phi_mappings.values() or list(phi_mappings.values()).count(temp_value) > 1:
                # if it doesn't end in a number, add _1, else increment the number
                if not re.search(r'_(\d+)$', temp_value):
                    new_value = temp_value + "_1"
                else:
                    new_value = re.sub(r'_(\d+)$', lambda x: f"_{int(x.group(1)) + 1}", temp_value)
                temp_value = new_value
            phi_mappings[key] = temp_value

5. Finally, I write a function to do the final de-identification:

def sanitize_text(text: str, complete_phi_mappings: dict) -> str:
    deidentified_text = text
    for phi, replacement in complete_phi_mappings.items():
        deidentified_text = deidentified_text.replace(phi, f"[{replacement}]")

    return deidentified_text

Output

Here's a snippet of the diff output from one of my test documents:

(all data is synthetic/generated using GPT-4o)

Obviouisly, if this data were in a structured, tabular format we could label various columns as PHI or not. But this is unstructured text which means our solution can apply to many different types of medical data.

Best Practices and Considerations

From my testing, I've found these practices to be crucial:

Consistency: Process the entire document to build a complete mapping before making replacements. This ensures that the same PHI element gets the same replacement token throughout.
Validation: Always validate the model's output. Include checks for empty keys/values and handle edge cases.
Performance: Process text in manageable chunks while maintaining context. This helps avoid token limits and improves accuracy.
Model Selection: Choose an appropriate model/prompt/context size combo. I found that smaller models like mistral-small:24b can be faster while still maintaining good accuracy for this task given the right prompting and document chunking.

Example Usage

Here's how to use the code:

# Load your medical text
sample_text = open("patient_chart.txt").read()

# Process the document
deidentified_text, phi_mappings = process_document(sample_text, '\n---\n')

# Save the results
with open("deidentified_text.txt", "w") as f:
    f.write(deidentified_text)
with open("phi_mappings.json", "w") as f:
    json.dump(phi_mappings, f, indent=2)

Future Improvements

I'm planning to enhance this solution with:

Creating specialized prompts for different models to compare performance (ideally smaller parameter count models that can run on even more systems)
Implementing confidence scores for each identified PHI element
Building a simple web interface for easy text processing

Conclusion

Using local LLMs for PHI de-identification offers a powerful, flexible, and secure solution for healthcare data processing. What excites me most is that this entire solution runs locally on consumer hardware - no cloud required. The approach I've described here provides a solid foundation that you can build upon for your specific needs.

The complete code is available in the GitHub repository. Feel free to try it out and let me know how it works for your use case!

Remember: While this solution can help with PHI identification, always have qualified personnel review the results before using de-identified data in production.

You can find me on LinkedIn | CTO & Partner @ EES.

Using Bright Data and OpenAI to Auto-Generate TLDR-Style Newsletters

Bryan Doss — Sun, 15 Dec 2024 17:04:39 +0000

This is a submission for the Bright Data Web Scraping Challenge: Build a Web Scraper API to Solve Business Problems

What I Built

I really enjoy the daily TLDR newsletters, but I often find it lacking when it comes to more niche news topics. The Bright Data web scraping challenge seemed like a good opportunity for me to tackle this problem.

The end result was a daily TLDR-style newsletter, featuring topics of my choice, scraped autonomously and written entirely by AI, delivered to my email inbox every morning.

This might also qualify under the "Most Creative Use of Web Data for AI Models." However, since I am not really training or fine-tuning an LLM I think the primary submission prompt "Build a Web Scraper API to Solve Business Problems" is most appropriate.

Demo

Full code can be found on GitHub.

Below is example output: a "niche" newsletter that was in my inbox at 8:30am this morning.

I think this qualifies as niche enough...

How I Used Bright Data

I made use of the Web Scraper API endpoints - specifically, the Reddit Post and Google News datasets.

The Idea

The idea is simple:

Find hot news posts on subreddit(s) of interest
Summarize the reddit comments (since I can't form an opinion on my own /s)
Collect links from other news outlets for diverse viewpoints
Send pretty email with links, discussion summaries, and emojis for that sweet, sweet 🤌 retention 🤌
Schedule steps 1-4 to run every day before I wake up so my newsletter is ready for my morning brew

APIs and Data Sources

We could signup for a Reddit developer account and fetch the extra news article links from various APIs, but using Bright Data means we don't have to go to multiple places for the data we want.

Besides the content itself, we will also need a way to summarize the reddit discussions and a way to format the email. For this I chose OpenAI's gpt-4o-mini.

Finally, we'll want to send this to ourselves as an email. I decided on Mailgun since it's simple enough to get started and they have a generous free tier.

Design

This is the high-level design I settled on for the end-to-end workflow. There are always better solutions, but this one worked well enough and made sense to me.

For full details, see the code on GitHub

After coding it up, I simply scheduled it to run every day at 8:30am.

Results

I'm very happy with the outputs!

The addition of the Google News aggregation step means I often get several links to multiple outlets covering the same topic. I like being able to read different articles on the same story. Oftentimes the first article I read from Reddit won't have the full facts or is biased one way or another (shocked-pikachu.jpg 👁👄👁).

The quality and consistency of the Bright Data API responses is impressive.

I'm also pleasantly surprised at the quality of gpt-4o-mini's HTML formatting given the lack of prompt engineering I did to write the emails.

"Email template:\n{html_template}\n\nArticles w/summary:{articles}\n---\nGiven the above email template and articles with summary, format the articles into the email template. Replace all brackets with content from articles/comments. Be sure to include the article links in href. Do not respond with anything other than raw HTML, do not enclose HTML in quotes.",

If you try this out for yourself, be sure to change the subreddit when making the call to get_newsletter(). Active subreddits with several new posts a day are the best candidates for fresh, interesting newsletters.

Checkout the demo on GitHub.

You can find me on LinkedIn | CTO & Partner @ EES.

Optimizing OpenAI’s GPT-4o-mini to Detect AI-Generated Text Using DSPy

Bryan Doss — Sat, 23 Nov 2024 15:32:22 +0000

Detecting AI-generated text has become a hot topic, with researchers and practitioners debating its feasibility and ethical implications. As models grow more sophisticated, distinguishing between human-written and AI-generated text becomes both an exciting challenge and a critical need.

In this post, we’ll explore how to harness DSPy’s optimization capabilities to fine-tune OpenAI’s GPT-4o-mini for this task using a fascinating dataset of 1.39 million text samples. By the end, you’ll know how to implement, evaluate, and optimize a basic AI-text detector using DSPy—no manual prompt engineering required.

Dataset Loading

First, let’s load the dataset, which contains text samples labeled as either human-written or AI-generated from varied human and LLM sources. To get started, ensure you’ve installed Python 3, along with the DSPy and hugging face datasets libraries:

pip install dspy datasets

The dataset is approximately 2GB in size, so depending on your internet speed, this step may take a few minutes (if you don't have a local dev environment or don't want to use one, AWS Cloud 9 is a great option).

Here’s the code to load and split the dataset evenly for training and testing:

from datasets import load_dataset

# Load the dataset
ds = load_dataset("artem9k/ai-text-detection-pile", split="train")

# For simplicity, we’ll do an even split of data for testing and training
NUM_EXAMPLES = 80  # Adjust this to experiment with dataset size
ds = ds.train_test_split(test_size=NUM_EXAMPLES, train_size=NUM_EXAMPLES)

Tip: You can adjust NUM_EXAMPLES to experiment with larger datasets or to reduce costs when running optimizations.

Model Setup

Next, we’ll create a basic DSPy predictor using OpenAI’s GPT-4o-mini. GPT-4o-mini is a lightweight version of OpenAI’s GPT-4o model, making it cost-efficient for experimentation. DSPy simplifies this process by using signatures, which define structured input-output mappings.

Replace "YOUR_API_KEY" with your OpenAI API key before running the code:

import dspy
from typing import Literal

# Initialize the OpenAI GPT-4o-mini model
lm = dspy.LM('openai/gpt-4o-mini', api_key="YOUR_API_KEY")
dspy.configure(lm=lm, experimental=True)

# Define the AI text detector signature
class DetectAiText(dspy.Signature):
    """Classify text as written by human or by AI."""
    text: str = dspy.InputField()
    source: Literal['ai', 'human'] = dspy.OutputField()

# Create a basic predictor
detector = dspy.Predict(DetectAiText)

Notice that we haven’t done any prompt engineering here. Instead, we rely on DSPy to handle that, as well as the input-output relationships automatically.

You can test the "detector" with some sample input:

print(detector(text="Hello world (this definitely wasn't written by AI)"))

The prediction will appear in the 'source' field of the output.

Evaluating the Detector

Now that we have a basic detector, let’s evaluate its performance using DSPy’s evaluation tools. For this, we’ll define a simple metric that checks if the model correctly predicts the text’s source (human or AI).

Here’s the code to set up and run the evaluation:

from dspy.evaluate import Evaluate

# Define a simple evaluation metric
def validate_text_source(example: dspy.Example, pred, trace=None) -> int:
    return 1 if example.source.lower() == pred.source.lower() else 0

# Transform the dataset into DSPy-compatible "Example" objects
dspy_trainset = [
    dspy.Example(source=x['source'], text=x['text']).with_inputs('text') for x in ds['train']
]
dspy_devset = [
    dspy.Example(source=x['source'], text=x['text']).with_inputs('text') for x in ds['test']
]

# Evaluate the detector
evaluator = Evaluate(devset=dspy_devset, num_threads=12)  # Adjust threads based on your system
evaluator(detector, metric=validate_text_source)

In my initial tests, I achieved an accuracy of 76%–81%. Note that results may vary due to the random sampling of the dataset.

Optimizing with DSPy

The real power of DSPy lies in its optimization capabilities. By using the MIPROv2 optimizer, we can improve the detector’s performance without manually tweaking prompts. The optimizer automates this process using few-shot examples, dynamic templates, and self-supervised techniques.

Here’s how to set up and run the optimizer:

import time
from dspy.teleprompt import MIPROv2

# Initialize the optimizer
teleprompter = MIPROv2(
    metric=validate_text_source, 
    auto="light"  # Options: light, medium, heavy
)

# Run the optimization
optimized_program = teleprompter.compile(
    detector.deepcopy(),  # Make a copy of the detector to optimize
    trainset=dspy_trainset,
    valset=dspy_devset,
)

# Save the optimized program for future use
optimized_program.save(f'detect_ai_mipro_optimized_{time.time()}.dspy')

Note: The cost for a single optimization run with the "light" preset is typically less than $0.50 for a dataset of 80 examples.

Results and Iteration

After running the optimization, I observed a significant performance boost. My first run achieved an accuracy of 91.25%, compared to the baseline’s 76%–81%. Subsequent runs ranged between 81.2% and 91.25%, demonstrating consistent improvements with minimal effort.

To load the optimized model for further use:

detector.load(path='detect_ai_mipro_optimized_XXXXX.dspy')

You can iterate further by:

Adjusting the optimizer’s auto parameter (light, medium, heavy), or setting hyper-parameters yourself.
Increasing the dataset size for training and evaluation.
Testing with more advanced or updated LLMs.

Conclusion

In just a few steps, we demonstrated how DSPy simplifies LLM optimization for real-world use cases. Without any manual prompt engineering, we achieved a measurable improvement in detecting AI-generated text. While this model isn’t perfect, DSPy’s flexibility allows for continuous iteration, making it a valuable tool for scalable AI development.

I'd highly recommend a read-through of DSPy’s documentation and experiment with other optimizers and LLM patterns.

Do I recommend running this in production? Absolutely not - but if you're so inclined I will likely update this post with instructions for deploying to AWS Lambda at some point.

Full code available on GitHub.

Question? Comments? Let me know, I look forward to seeing what you build with DSPy!

You can find me on LinkedIn | CTO & Partner @ EES.

Adding Web Scraping and Google Search to AWS Bedrock Agents

Bryan Doss — Wed, 17 Jul 2024 17:27:07 +0000

Motivation

After all of the AWS product announcements at the NYC Summit last week, I wanted to start testing out AWS Bedrock Agents more thoroughly for myself. Something clients often ask for is the ability for their LLM workflows to have access to the web.

There is a web scraper example from AWS that covers this, but I wanted to make a version for NodeJS in TypeScript. I also wasn't happy with the Google search capability relying on web scraping, so I swapped it out for the Google custom search API. My solution will also be making use of the AWS CLI and Docker images to make things more consistent.

Overview

(GitHub project available at end of article)

Prerequisites:

AWS CLI (v2)
Docker
NodeJS 20.x
AWS Account
Google Custom Search API Key

What we want to do is create a Bedrock agent and attach an action group with a Lambda function that can be called by the agent to perform google searches and scrape web content. We'll accomplish this by defining a Lambda function using Docker and then attaching that function to the agent.

Tasks:

Write function(s) to perform web scraping and Google search
Build Docker image to test functions locally
Deploy Docker image to AWS ECR
Creating Lambda function using ECR image as source
Set up IAM roles/permissions
Create Bedrock agent to use new Lambda function

Creating the Lambda function

Let's start by defining a Lambda function using Docker.

Why use Docker? Usually, I deploy Lambda-based apps using AWS SAM but I wanted to try something different this time. Plus docker images are easier to test with locally (in my experience).

We'll start by following the AWS documentation for deploying a Typescript on NodeJS container image.

I encourage you to read the AWS docs, but this is what we're going to do to get started (I'm using Node 20.x):

npm init
npm install @types/aws-lambda esbuild --save-dev 
npm install @types/node --save-dev
npm install typescript --save-dev

Let's also install cheerio since we'll need it for web scraping later:

npm install cheerio

Then add a build script to the package.json file:

...
"scripts": {
  "build": "esbuild index.ts --bundle --minify --sourcemap --platform=node --target=es2020 --outfile=dist/index.js"
}
...

Create a Dockerfile. I modified the example Dockerfile from AWS to use the nodejs20 as base:

FROM public.ecr.aws/lambda/nodejs:20 as builder
WORKDIR /usr/app
COPY package.json ./
RUN npm install
COPY index.ts ./
RUN npm run build

FROM public.ecr.aws/lambda/nodejs:20
WORKDIR ${LAMBDA_TASK_ROOT}
COPY --from=builder /usr/app/dist/* ./

CMD ["index.handler"]

Great, now create an index.ts. Here's the placeholder index.ts provided by AWS and is good for testing our setup:

import { Context, APIGatewayProxyResult, APIGatewayEvent } from 'aws-lambda';

export const handler = async (event: APIGatewayEvent, context: Context): Promise<APIGatewayProxyResult> => {
    console.log(`Event: ${JSON.stringify(event, null, 2)}`);
    console.log(`Context: ${JSON.stringify(context, null, 2)}`);
    return {
        statusCode: 200,
        body: JSON.stringify({
            message: 'hello world',
        }),
    };
};

Build and run the container (name it whatever you like, I used bedrock-scraper:latest):

docker build --platform linux/amd64 -t bedrock-scraper:latest .
docker run --platform linux/amd64 -p 9000:8080 bedrock-scraper:latest

If we did everything properly we should be able to invoke the function and get our test result:

curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'

And we should see:

{"statusCode":200,"body":"{\"message\":\"hello world\"}"}%

Everything's working well! Now we can start writing the "functions" that our agent will eventually use.

Add the Web Scraper (cheerio)

We're going to use cheerio to parse the content from websites ("web scraping").

First, we'll add import and typing at the top so we don't forget to return all properties required by the Bedrock Agent.

import { Context, APIGatewayEvent } from 'aws-lambda';
import * as cheerio from 'cheerio';

interface BedrockAgentLambdaEvent extends APIGatewayEvent {
  function: string;
  parameters: any[];
  actionGroup: string;
}

interface BedrockResult {
  messageVersion: string;
  response: {
    actionGroup: string;
    function: string;
    functionResponse: {
      responseState?: string;
      responseBody: any;
    }
  }
}

...

Then we can modify the lambda handler() function to accept the new event type and return the new result type:

...

export const handler = async (event: BedrockAgentLambdaEvent, context: Context): Promise<BedrockResult> => {

...

How will our Lambda function know what URL to scrape? It will be passed from the Agent via the Event parameters. Inside our handler() we can add the following

let parameters = event['parameters'];

Let's assume the to-be-implemented agent is going to pass us a url parameter. Based on the AWS docs, we can access this parameter like so:

let url = parameters.find(param => param.name === 'url')?.value || '';

Next, we can get the html content using cheerio:

const response = await fetch(url);
const html = await response.text();
const $ = cheerio.load(html);

Now let's parse out all the unnecessary tags and get the website text:

// Remove extraneous elements
$('script, style, iframe, noscript, link, meta, head, comment').remove();
let plainText = $('body').text();

Finally we can return the content in the format that Bedrock needs:

let actionResponse = {
  'messageVersion': '1.0',
  'response': {
    'actionGroup': event['actionGroup'] || '',
    'function': event['function'] || '',
    'functionResponse': {
      'responseBody': {
        'TEXT': {
          'body': '',
        }
      }
    }
  }
};
actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
  'text': plainText,
});
return actionResponse;

Rebuild and rerun the container to test our changes:

docker build --platform linux/amd64 -t bedrock-scraper:latest .
docker run --platform linux/amd64 -p 9000:8080 bedrock-scraper:latest

Invoke the scrape function, we need to pass the parameters the same way the agent will, in the format we defined above:

curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"parameters":[{"name":"url","value":"https://google.com"}]}'

We should get back some text that looks like the google home page.

{"messageVersion":"1.0","response":{"actionGroup":"","function":"","functionResponse":{"responseBody":{"TEXT":{"body":"{\"text\":\"Search Images Maps Play YouTube News Gmail Drive More »Web History | Settings | Sign in Advanced searchAdvertisingBusiness SolutionsAbout Google© 2024 - Privacy - Terms          \"}"}}}}}

Excellent, our web scraping function is setup! Let's move on to the Google search.

Add the Google Search Tool (custom search API)

Before setting up search, you should follow Google's documentation on creating a search engine and obtaining an api key.

With our custom search ID and API key in-hand, it's simple to add a condition for it in our handler. I'm going to refactor the handler function a bit and add a new Google search section:

export const handler = async (event: BedrockAgentLambdaEvent, context: Context): Promise<BedrockResult> => {
  let agentFunction = event['function'];
  let parameters = event['parameters'];

  let actionResponse = {
    'messageVersion': '1.0',
    'response': {
      'actionGroup': event['actionGroup'] || '',
      'function': event['function'] || '',
      'functionResponse': {
        'responseBody': {
          'TEXT': {
            'body': '',
          }
        }
      }
    }
  };

  if (agentFunction === 'scrape') {
    // get URL from parameters
    let url = parameters.find(param => param.name === 'url')?.value || '';

    if (!url) {
      actionResponse['response']['functionResponse']['responseState'] = 'FAILURE';
      actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
        'error': 'URL not found in parameters',
      });
      return actionResponse;
    }

    const response = await fetch(url);
    const html = await response.text();
    const $ = cheerio.load(html);
    // Remove extraneous elements
    $('script, style, iframe, noscript, link, meta, head, comment').remove();

    let plainText = $('body').text();
    console.log({plainText});

    // Limit of Lambda response payload is 25KB
    // https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html
    const maxSizeInBytes = 20 * 1024;
    if (Buffer.byteLength(plainText, 'utf8') > maxSizeInBytes) {
      while (Buffer.byteLength(plainText, 'utf8') > maxSizeInBytes) {
        plainText = plainText.slice(0, -1);
      }
      plainText = plainText.trim() + '...'; // Add an ellipsis to indicate truncation
    }
    console.log({plainText});

    actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
      'text': plainText,
    });
    return actionResponse;

  } else if (agentFunction === 'google_search') {
    let query = parameters.find(param => param.name === 'query')?.value || '';

    if (!query) {
      actionResponse['response']['functionResponse']['responseState'] = 'FAILURE';
      actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
        'error': 'Query not found in parameters',
      });
      return actionResponse;
    }

    const googleParams = {
      key: process.env.GOOGLE_SEARCH_KEY,
      cx: process.env.GOOGLE_SEARCH_CX,
      q: query,
    };

    const queryString = Object.keys(googleParams)
      .map(key => key + '=' + googleParams[key])
      .join('&');

    const response = await fetch(`https://www.googleapis.com/customsearch/v1?${queryString}`);
    const data = await response.json();

    if (data.items) {
      // only return title and link of first 10 results for smaller response payload
      const results = data.items.map((item: any) => {
        return {
          title: item.title,
          link: item.link,
        };
      }).slice(0, 10);

      actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
        'results': results,
      });
      return actionResponse;
    } else {
      actionResponse['response']['functionResponse']['responseState'] = 'FAILURE';
      actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
        'error': 'No results found',
      });
      return actionResponse;
    }
  } else {
    actionResponse['response']['functionResponse']['responseState'] = 'FAILURE';
    actionResponse['response']['functionResponse']['responseBody']['TEXT']['body'] = JSON.stringify({
      'error': 'Function not found',
    });
    return actionResponse;
  }
};

Interesting changes to point out:

If condition based on the function name passed to our Lambda from Bedrock
Use of environment variables instead of hardcoding our Google Search API key and Custom Search Engine ID
Truncate the response for both google_search and scrape functions due to Lambda/Bedrock quota limits
Added some edge cases & error handling

Let's test it!

Now that we are dealing with API keys as env variables we should pass them in to docker at run time:

docker build --platform linux/amd64 -t bedrock-scraper:latest .
docker run -e GOOGLE_SEARCH_KEY=YOUR_SEARCH_KEY -e GOOGLE_SEARCH_CX=YOUR_CX_ID --platform linux/amd64 -p 9000:8080 bedrock-scraper:latest

Example cURL to test

curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"function":"google_search", "parameters":[{"name":"query","value":"safest cities in USA"}]}'

My output

{"messageVersion":"1.0","response":{"actionGroup":"","function":"google_search","functionResponse":{"responseBody":{"TEXT":{"body":"{\"results\":[{\"title\":\"The 10 Safest Cities in America | Best States | U.S. News\",\"link\":\"https://www.usnews.com/news/cities/slideshows/safest-cities-in-america\"}...

Perfect! Now let's deploy to Lambda so we can start using these functions.

Deploy Lambda Function

Before connecting to Bedrock, we'll need to deploy our lambda function. To do this, we can continue with the AWS documentation for "Deploying the Image".

Start by creating an ECR repository and pushing our image to it.
(Be sure to replace 111122223333 and us-east-1 with your account ID and region)

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
aws ecr create-repository --repository-name bedrock-scraper --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
docker tag bedrock-scraper:latest 111122223333.dkr.ecr.us-east-1.amazonaws.com/bedrock-scraper:latest
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/bedrock-scraper:latest

Next, create a role for the Lambda function and create the Lambda function itself:
(Remember to replace 111122223333 and us-east-1 with your account ID and region, YOUR_SEARCH_KEY and YOUR_CX_ID with your Google search key and CX ID)

aws iam create-role \
    --role-name lambda-ex \
    --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
aws lambda create-function \
  --function-name bedrock-scraper \
  --package-type Image \
  --code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/bedrock-scraper:latest \
  --role arn:aws:iam::111122223333:role/lambda-ex \
  --timeout 30 \
  --environment "Variables={GOOGLE_SEARCH_KEY=YOUR_SEARCH_KEY,GOOGLE_SEARCH_CX=YOUR_CX_ID}"

After the Lambda is done creating, we can test using the AWS cli to make sure our function works in Lambda:

aws lambda invoke --function-name bedrock-scraper --cli-binary-format raw-in-base64-out --payload '{"function":"google_search", "parameters":[{"name":"query","value":"safest cities in USA"}]}' response.json

If we inspect response.json it should look something like:

{
    "messageVersion": "1.0",
    "response": {
        "actionGroup": "",
        "function": "google_search",
        "functionResponse": {
            "responseBody": {
                "TEXT": {
                    "body": "{\"results\":[{\"title\":\"The 10 Safest Cities in America | Best States | U.S. News\",\"link\":\"https://www.usnews.com/news/cities/slideshows/safest-cities-in-america\"}..."
                }
            }
        }
    }
}

Excellent - now let's expose this capability to a Bedrock agent.

Add Bedrock Action Group and Permissions

We first need to create a basic Bedrock agent. We can do this via the CLI. If you'd like more details on this process see the AWS documentation on
creating a Bedrock agent and adding an action group to a Bedrock Agent.

Start by creating a policy and role for the agent. This allows the agent to invoke the foundation model in Bedrock (Check your account to make sure the model you want is available in your region). I'll be naming mine BedrockAgentInvokeClaude and applying to a role called bedrock-agent-service-role.
(Remember to replace 111122223333 and us-east-1 with your account ID and region)

aws iam create-policy --policy-name BedrockAgentInvokeClaude --policy-document '{"Version":"2012-10-17","Statement":[{"Sid":"VisualEditor0","Effect":"Allow","Action":"bedrock:InvokeModel","Resource":["arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0","arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0","arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0","arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2","arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2:1","arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-instant-v1"]}]}'
aws iam create-role --role-name bedrock-agent-service-role --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"bedrock.amazonaws.com"},"Action":"sts:AssumeRole","Condition":{"StringEquals":{"aws:SourceAccount":"111122223333"},"ArnLike":{"AWS:SourceArn":"arn:aws:bedrock:us-east-1:111122223333:agent/*"}}}]}'
aws iam attach-role-policy --role-name bedrock-agent-service-role --policy-arn arn:aws:iam::111122223333:policy/BedrockAgentInvokeClaude

Now we can create the Agent using Claude v3 sonnet as the model (you may need to request access to some models):
(Be sure to use the ARN of your new role from above)

aws bedrock-agent create-agent \
    --agent-name "scrape-agent" --agent-resource-role-arn arn:aws:iam::111122223333:role/bedrock-agent-service-role \
    --foundation-model anthropic.claude-3-sonnet-20240229-v1:0 \
    --instruction "You are a helpful agent that can search the web and scrape content. Use the functions available to you to help you answer user questions."

Using the agentArn of our new agent, give it permission to invoke the lambda function:
(Remember to use your own agent ARN/ID here)

aws lambda add-permission \
    --function-name bedrock-scraper \
    --statement-id bedrock-agent-invoke \
    --action lambda:InvokeFunction \
    --principal bedrock.amazonaws.com \
    --source-arn arn:aws:bedrock:us-east-1:111122223333:agent/999999

Now, using our Lambda ARN from previously, let's add an action group:
(Remember to use your own Lambda ARN and agent ID here)

aws bedrock-agent create-agent-action-group \
    --agent-id 999999 \
    --agent-version DRAFT \
    --action-group-executor lambda=arn:aws:lambda:us-east-1:111122223333:function:bedrock-scraper \
    --action-group-name "search-and-scrape" \
    --function-schema '{"functions": [{"name":"google_search","description":"Search using google","parameters":{"query":{"description":"Query to search on Google","required":true,"type":"string"}}}, {"name":"scrape","description":"Scrape content from a URL","parameters":{"url":{"description":"Valid URL to scrape content from","required":true,"type":"string"}}}]}'

Now prepare the agent:
(Remember to use your own agent ID here)

aws bedrock-agent prepare-agent --agent-id 999999

Now, FINALLY, we can test our agent.

Testing

It's easy to test the agent using the AWS console.

Go to Bedrock > Agents and you should see your new agent. Open it and click Test. Ask it a question only an agent with access to the web could answer:

Cleanup && Thoughts

This was a quick-and-dirty way to get a Bedrock agent up and running. I will eventually turn this into a CloudFormation template to make it easier to deploy (star the GitHub for updates).

If you no longer want them, you can delete the Lambda function, ECR image, Bedrock agent, and IAM resources:
(Don't forget to use your own account ID's and ARNs here)

aws bedrock-agent delete-agent --agent-id 999999
aws iam detach-role-policy --role-name bedrock-agent-service-role --policy-arn arn:aws:iam::111122223333:policy/BedrockAgentInvokeClaude
aws iam delete-policy --policy-arn arn:aws:iam::111122223333:policy/BedrockAgentInvokeClaude
aws iam delete-role --role-name bedrock-agent-service-role
aws lambda delete-function --function-name bedrock-scraper
aws iam detach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name lambda-ex
aws ecr delete-repository --repository-name bedrock-scraper --force

For more information on Bedrock agents and how to use them, see the AWS documentation.

Full code available on GitHub.

Question? Comments? Let me know, I look forward to seeing what you build with Bedrock!

You can find me on LinkedIn | CTO & Partner @ EES.