DEV Community: Kavin HBN

We tried Reducto so our RAG pipeline would stop hallucinating table data

Kavin HBN — Thu, 27 Aug 2026 17:19:56 +0000

If you've ever built a RAG pipeline on top of real-world PDFs — not clean text files, but actual scanned evidence, policy docs, spreadsheets exported as PDFs, forms with checkboxes — you already know the dirty secret: parsing is the hard part, not the retrieval part.

I work on a GRC platform. Think audit evidence, compliance policies, control matrices — the kind of documents where a merged table cell or a checkbox actually matters, because someone downstream is going to make a judgment call based on what your pipeline extracted. "Close enough" text extraction isn't close enough when the output feeds into an AI evaluation step that's supposed to tell an auditor whether a control passed.

The problem we kept hitting

Our first pass used the usual suspects for PDF-to-text. It worked fine for prose. It fell apart the moment a document had:

Tables with merged cells or nested headers
Multi-column layouts that got read left-to-right across columns instead of down each one
Checkboxes and form fields that just vanished
Scanned pages that were "text" in name only

The output would look plausible, which is almost worse than it looking broken — you don't notice the row got scrambled until someone downstream asks why the AI matched evidence to the wrong control.

Where Reducto came in

We started evaluating Reducto as a parsing layer sitting in front of our RAG/matching pipeline instead of trying to keep patching regex and heuristics forever. The pitch is basically: send it the raw document, get back structured, LLM-ready output — markdown or JSON, tables preserved as tables, figures called out, page and bounding-box citations attached to every chunk.

That last part turned out to matter more than I expected. Having citations tied back to a literal region of the source page means when the AI pipeline says "this evidence supports this control," you can actually point at where on the page it's pulling that from, instead of trusting a black box. For anything audit-adjacent, that traceability isn't a nice-to-have, it's basically the whole requirement.

What actually got better

Table fidelity went from "usually fine" to "actually fine," including the annoying merged-header cases
We stopped hand-rolling special cases for scanned vs native PDFs
The chunking we fed into our matching logic got noticeably cleaner, which meant fewer weird false-positive matches
Debugging got easier because we could trace a bad match back to a specific bounding box instead of guessing

What I'd tell someone evaluating it

It's not magic, and it's not free — it's priced per page, so if you're processing huge volumes you'll want to actually run the math against your document mix before committing. It also won't fix a bad retrieval or matching strategy sitting downstream of it; it just gives you a much better foundation to build that strategy on.

If your RAG pipeline is choking on real-world documents rather than clean sample PDFs, and you've already ruled out "just write more regex," it's worth a real trial run against your actual document set rather than a demo PDF. The gap between "looks fine on a demo" and "survives your actual messy corpus" is where most of these tools live or die, and that's true of any parsing layer, not just this one.

Curious if anyone else building compliance/audit-adjacent tooling has landed on something different for this — always interested in comparing notes on what breaks first.

Trying it before committing to it

The free tier is generous enough to actually run a real trial instead of just kicking the tires on a sample PDF — you can throw your own messy documents at it and see how the table/checkbox/scan handling holds up before you touch a credit card. That mattered to us, because a demo PDF always looks great; it's your own weird internal export that tells you the truth.

The API is straightforward — send a document, get back structured output — and webhooks mean you're not stuck polling a job status endpoint for larger files, which is nice when you're parsing in bulk instead of one-off.

Worth noting: Vanta uses it too, which was a decent signal for us since they're solving a similar-shaped problem — compliance evidence, policy docs, the same kind of messy-document-meets-structured-output challenge. Wasn't the deciding factor, but it didn't hurt.

If you're past the free tier and need real volume or specific compliance guarantees (SOC 2, data residency, that kind of thing), that's an enterprise conversation with their team rather than a self-serve toggle — expected for anything handling sensitive documents at scale, but worth knowing going in so it doesn't surprise you mid-eval.

Why I’m Thinking of Switching My Portfolio to Astro.js ..

Kavin HBN — Sat, 04 Jul 2026 08:12:55 +0000

Why I'm Thinking of Switching My Portfolio to Astro.js

Lately I have been spending most of my time building auditing dashboards. Working on data-highly interactive applications changes the way you think. After a while my default workflow became simple: create a new React + Vite project. Start coding.

It's a stack for building web applications.

When I looked at my personal portfolio and blog, I stopped and asked myself:

Why am I using the setup for a website that is mostly static?

A portfolio is not a dashboard. It does not manage state, update data in real time, or require every component to become interactive the moment the page loads.

Yet with my React setup the browser still has to download and execute JavaScript for the entire application before everything becomes interactive.

While browsing through developer blogs and discussions, I kept seeing one framework mentioned again and again: Astro.

The more I read about it, the more it seemed designed for exactly this type of website.

The Problem with Hydrating Everything

A typical React application works by hydrating the page.

For example, a React application starts like this:


import ReactDOM from "dom/client";

import App from "./App";

ReactDOM.createRoot(document.getElementById("root")).render(

<App />

);

Everything inside ``eventually becomes part of one large JavaScript application.

Before users can fully interact with the page, the browser needs to:

Download the JavaScript
Parse it
Execute it
Hydrate the UI

For applications like dashboards admin panels or collaborative tools, this trade-off is completely reasonable.

For a portfolio?

Most visitors just want to

Read about you
View your projects
Open your GitHub
Read your blog

Hydrating the page feels unnecessary.

I mean think about it. My portfolio does not need to be interactive all the time.

Astro Takes an Approach

Astro follows a different philosophy.

Of assuming everything needs JavaScript, it assumes nothing does.

A simple Astro page looks like this:

`astro

const title = "My Portfolio";

{title}

Hello I'm Kavin

Welcome to my portfolio.

When you build the project:

`bash

npm run build

Astro outputs HTML.

That means visitors immediately receive content without waiting for a JavaScript bundle.

I like that.

Islands Architecture

One of Astro's interesting ideas is **island architecture.

By making the whole page interactive, Astro only hydrates the components that actually need JavaScript.

For example:

`astro

import ThemeToggle from "../components/ThemeToggle.jsx";

import ProjectCarousel from "../components/ProjectCarousel.jsx";

My Portfolio

Here the page itself remains static.

Only the components that need interactivity receive JavaScript.

That's really cool.

Client Directives

Astro gives you control over when a component should become interactive.

`client:load`

`astro

What it does

Downloads JavaScript immediately
Hydrates soon as the page loads

Best for

Theme toggles
Navigation menus
Search boxes
buttons

I can see why this is useful.

`client:visible`

`astro

What it does

Waits until the component appears on the screen
Downloads JavaScript only when needed

Imagine your portfolio contains an interactive project carousel near the bottom of the page.

If a visitor never scrolls far, Astro never downloads its JavaScript.

That's bandwidth saved without writing any optimization code.

Why This Matters

Instead of sending JavaScript for everything upfront, Astro sends JavaScript only where it's actually needed.

That means:

Smaller JavaScript bundles
Faster page loads
Lower memory usage
Better Core Web Vitals
Less work for the browser

For content websites, this approach makes a lot of sense.

I think it's a fit for my portfolio.

SEO Benefits

Another thing I like is how Astro handles SEO.

Since pages are rendered as HTML by default, search engines can immediately read the following:

Page title
Meta description
Headings
Content
links

They don't have to wait for a large JavaScript application to finish executing before indexing the page.

For blogs and portfolios, that's an advantage.

Where Astro Makes the Sense

After reading more about Astro, I realized it fits perfectly for websites where content's the main focus.

Some examples include:

Developer portfolios
Personal blogs
Documentation websites
Company landing pages
Marketing websites
E-commerce storefronts where fast loading improves user experience

That does not mean React is obsolete.

If I were building another auditing dashboard with forms, charts, filters, and live updates, I'd still reach for React without hesitation.

The tool simply matches the problem.

I like that.

Final Thoughts

This was not really about finding a "framework.

It was about choosing the one for the job.

For years my mindset was

"I'll just use React."

Now it's becoming:

"What does this project actually need?"

For interactive web applications, React is still one of the best choices available.

For a portfolio or blog Astro's approach of shipping static HTML first and loading JavaScript only when it's needed feels much more appropriate.

I'm seriously considering rebuilding my portfolio with Astro—not because React is not good enough. Because Astro seems like the better fit for the kind of website I'm trying to build.

Sometimes the biggest performance improvement does not come from writing code.

It comes from choosing the tool before writing any code at all.

Git for New Devs: Your Code's Grand Adventure !

Kavin HBN — Mon, 23 Jun 2025 10:39:13 +0000

Git for Beginners: A Simple Guide to Your Git Workflow

When you are learning Git, the number of commands can feel overwhelming.

The good news is that most of your day-to-day work follows the simple Git workflow.

Once you understand that Git workflow, handling problems like merge conflicts or rejected Git pushes becomes much easier.

Git for beginners can be easy to learn.

Think of Git as a journal for your project.

Every meaningful change is recorded so you can track your progress collaborate with others using Git and even travel back in time if something goes wrong with Git.

The Normal Git Workflow

Most of the time you will follow these steps in your Git workflow.

Step 1: Initialize Your Git Repository

When starting a project initialize Git inside your project folder using Git.

If you are using GitHub connect your Git repository to the remote Git repository using Git.


git init

If you are using GitHub you can connect your Git repository to the remote Git repository using Git.


git remote add origin https://github.com/your-username/your-repository.git

Now your local project knows where it should push and pull changes using Git.

Step 2: Stage Your Changes in Git

After writing or modifying code tell Git which files should be included in the next Git commit.

Stage every changed file in Git:


git add.

Or stage a file in Git:


git add app.js

Step 3: Create a Commit in Git

A commit in Git is a snapshot of your project at a specific point in time using Git.

Write meaningful commit messages that explain what changed in your Git project not that something changed in your Git project.


git commit -m " project setup"

Good examples of commit messages in Git are:


git commit -m "Add user authentication"

git commit -m "Fix login validation bug"

git commit -m "Update portfolio homepage"

Step 4: Push Your Changes in Git

Upload your commits to GitHub using Git.

The first push using Git:


git push -u origin main

Future pushes using Git:


git push

At this point your work is safely stored both locally and on GitHub using Git.

When Things Do Not Go as Planned in Git

Working is simple in Git.

Working with developers introduces a few common situations you will eventually encounter in Git.

Fortunately they are easy to fix once you understand what is happening in Git.

Problem 1: Push Rejected in Git

Sometimes Git refuses your push. Shows a message similar to this in Git:


Updates were rejected because the remote contains work that you do not have locally.

This means someone has already pushed commits to GitHub that you do not have on your computer using Git.

Git blocks your push to prevent overwriting their work in Git.

Solution: Pull First in Git

Download the changes from GitHub using Git.


git pull origin main

If your changes and the remote changes do not overlap Git merges everything automatically using Git.

Then simply push again using Git.


git push

Problem 2: Merge Conflict in Git

Sometimes both you and another developer edit the part of the same file in Git.

Git does not know which version should be kept in Git.

Of guessing it asks you to decide in Git.

You will see something to this in Git:


<<<<<<< HEAD

My version

=======

Their version

>>>>>>> origin/main

How to Resolve It in Git

Open the file and decide which code should remain in Git.

You can keep your version keep their version or combine both versions in Git.

After editing the file remove all the conflict markers in Git.

Then stage the file in Git.


git add filename

Create a commit in Git.


git commit -m "Resolve merge conflict"

Finally push your updated code in Git.


git push

Working Safely with Branches in Git

Branches let you develop features without affecting the main project in Git.

Create a new branch in Git.


git checkout -b feature/login

Work in Git.


git add.

git commit -m "Add login page"

Switch to the main branch in Git.


git checkout main

Merge your feature in Git.


git merge feature/login

Once merged your new feature becomes part of the project in Git.

Undoing Commits in Git

Everyone makes mistakes in Git.

Git provides ways to undo changes in Git.

View your commit history in Git.


git log --oneline

Undo the commit but keep your code in Git.


git reset --soft HEAD~1

Undo the commit and permanently remove those changes in Git.


git reset --hard HEAD~1

Use --hard carefully because the discarded changes cannot be recovered easily in Git.

Understanding `git status` in Git

One of the useful commands is in Git:


git status

It tells you exactly what is happening inside your repository in Git.

Common status indicators include:

| Symbol | Meaning

| ------ | ------------------------------ |

M` | Modified file |

| A | Newly added file |

| D | Deleted file |

| U | Unmerged file (merge conflict) |

| ?? | Untracked file |

Running git status frequently helps you understand what Git is tracking before committing in Git.

Common Git Workflow Cheat Sheet in Git

Initialize a repository in Git:

`bash

git init

Stage files in Git:

`bash

git add.

Create a commit in Git:

`bash

git commit -m "Your message"

Push to GitHub in Git:

`bash

git push

Download changes in Git:

`bash

git pull

Create a new branch in Git:

`bash

git checkout -b feature-name

Switch branches in Git:

`bash

git checkout main

Merge a branch in Git:

`bash

git merge feature-name

View commit history in Git:

`bash

git log --oneline

Check repository status in Git:

`bash

git status

Final Thoughts on Git

Git can seem intimidating at first but most developers use the same handful of commands every day in Git.

The basic Git workflow is simple:

Make changes in Git.
Stage them with git add in Git.
Save them with git commit in Git.
Share them using git push in Git.

As you collaborate with others you will occasionally encounter pull requests merge conflicts and branches in Git.

These are not signs that something's wrong. They are simply part of working with version control in Git.

The more you practice the more Git starts to feel less like a list of commands and like a reliable safety net for your code, in Git.

DEV Community: Kavin HBN

We tried Reducto so our RAG pipeline would stop hallucinating table data

The problem we kept hitting

Where Reducto came in

What actually got better

What I'd tell someone evaluating it

Trying it before committing to it

Why I’m Thinking of Switching My Portfolio to Astro.js ..

Why I'm Thinking of Switching My Portfolio to Astro.js

Why am I using the setup for a website that is mostly static?

The Problem with Hydrating Everything

Astro Takes an Approach

Hello I'm Kavin

Islands Architecture

My Portfolio

Client Directives

client:load

client:visible

Why This Matters

SEO Benefits

Where Astro Makes the Sense

Final Thoughts

Git for New Devs: Your Code's Grand Adventure !

Git for Beginners: A Simple Guide to Your Git Workflow

The Normal Git Workflow

Step 1: Initialize Your Git Repository

Step 2: Stage Your Changes in Git

Step 3: Create a Commit in Git

Step 4: Push Your Changes in Git

When Things Do Not Go as Planned in Git

Problem 1: Push Rejected in Git

Solution: Pull First in Git

Problem 2: Merge Conflict in Git

How to Resolve It in Git

Working Safely with Branches in Git

Undoing Commits in Git

Understanding git status in Git

Common Git Workflow Cheat Sheet in Git

Final Thoughts on Git

`client:load`

`client:visible`

Understanding `git status` in Git