You: “What even is RAG?”

Tbh, shit’s confusing as hell at first. But the deeper you go, the better it gets.

What LLMs OFTEN get wrong at

We all have had this moment before vivas.

Cram all the information a few hours before your turn.

Then yap at the external examiner and hope for the best. But then the examiner asks: “Okay, but why did you make that decision in your project?”

Now all quiet at the viva hall.

LLMs do just that.

They are designed to generate plausible responses.

Which means…they simply dunno how to say ‘I dunno’.

And then there’s the problem of outdated information.

Imagine your examiner asks:

“Why did you use that approach when there’s a newer and better way of doing it?”

You’re in trouble.

LLMs can face the same problem when their knowledge doesn’t contain the latest information.

So… How do we give an LLM the information it needs when it needs it?

Introducing Retrieval-Augmented Generation

Press enter or click to view image in full size

Don’t get intimated by the name. Just a fancy name for a simple process: find relevant info., give it to the model and let it generate an answer.

That’s it.

Let’s break down what’s actually happening under the hood.

Understanding the problem

Picture this: you’re building an AI assistant for your company.

Now, the company has several documents: employee handbook, internal FAQs, security policies, etc.

Let’s say that you’re finished building it. People will want to test it for sure. So, someone asks the model:

“How many days of parental leave do I get?”

Now the problem is, the model doesn’t know what your company policies are. Nor can you dump a 500 documents [each of several hundred pages] on a poor model and ask it to spit out an answer [this leads to overfitting, context window overload, etc.]

Process behind RAG

Instead of asking the LLM to answer the question from its own knowledge, we first retrieve relevant information from our own knowledge base. Then we give that information to the LLM.

The LLM uses that information to generate the answer.

This means the model doesn’t need to know everything. We just need to feed it the right information at the right time.

But now we have another problem: How do we figure out which information is relevant in the first place?

Retrieval

We don’t want to send all of them to the LLM for every question. We first need to find the relevant bits, as finding every single one is resource-intensive, very time-consuming!

So we split the documents into smaller pieces called chunks. One chunk might contain the parental leave policy, another the security policy, and another the expense policy.

How do we find the right chunk?

A user might ask: “How long can I stay away from work after having a baby?”

The document says: “Employees are entitled to 26 weeks of parental leave.”

Different words. Same meaning. For tackling this unique issue, we introduce embeddings.

Embeddings

An embedding converts text into numbers that capture its meaning. Similar text ends up close together in this mathematical space [we use a terminology called vector distance: meaning, how far are 2 vectors away from each other?].

We store these embeddings in a vector database. When a question comes in, we embed it too and search for the closest chunks.

That gives us the relevant chunks, which are then passed to the LLM as context.

Augmentation

We’ve found the relevant chunks.

Now we add them to the LLM’s context alongside the user’s question:

Context:
Employees are entitled to 26 weeks of parental leave.

Question:
How long can I stay away from work after having a baby?

The LLM now has the information it needs to answer.

Generation

Now the LLM does what it’s extremely good at: generating the answer.

It takes the user’s question and the retrieved context, then produces a response:

“You’re entitled to 26 weeks of parental leave.”

That’s the final step from the process of: Retrieve → Augment → Generate

But there’s a catch.

The LLM can only work with the information we retrieve. If we retrieve the wrong chunk, the answer can still be wrong.

Here’s an example:

Question: “How long is parental leave?”

Retrieved: “Notify your manager 30 days before taking parental leave.”

Answer: “You need to notify your manager 30 days before taking parental leave.”

How to make it better, then?

So, how do we make sure we retrieve the right information?

A few things matter:

Chunking: How we split documents can determine whether the useful context stays together.

Embeddings: Better embeddings make it easier to match questions with relevant content.

Search: We can combine semantic search with keyword search to catch both meaning and exact terms.

Reranking: Retrieve a few candidates first, then rank them again to find the most relevant ones.

The goal is simple: Get the right context in front of the LLM.

To conclude

RAG isn’t magic.

Find the right information.
Give it to the LLM.
Let it answer.

That’s it.

The LLM doesn’t need to know everything.

It just needs the right context at the right time.

And in RAG, that’s the real game: Garbage in, garbage out and vice versa.

Now you know what all the “RAG this, RAG that” is about.

We are thrilled to offer you a position...

I stared at it for a few seconds before it finally sank in.

Forty days earlier, I had walked out of the NIMCET exam hall convinced I'd wasted an entire year.

Funny how quickly life can change.

The D-Day: June 6

History remembers it as one of humanity's greatest victories.

I remember it as the day I walked out of an exam hall completely broken.

I still remember how innocently I walked into the tech lab, feeling prepared and enthused.

"What the fuck was that?!"

I had found myself in an utterly hope-shattering predicament. Not a single section that was doable. My stress levels were through the fucking roof.

I walked out a changed person. Once full of hope, I was now nothing but a husk, trudging all the way home.

I had two choices

Complain about the miserable experience, complain that one specific rule made you lose marks, complain that people who didn't study as hard as I did got more marks than me.

Complain, complain, complain.

OR

Just get over it and grind.

There is a concept in my native language: விடாமுயற்சி [perseverance].

And the wise old men say: perseverance is king.

So be it.

I am restarting my DSA prep today. I am hunting an internship today. I am building projects starting today...I said to myself the evening after NIMCET, staring at the LeetCode problem section page.

The grind begins

Every day, my job was to catch the morning job postings and then follow-up in the evening.

LinkedIn. Twitter [now known as X]. Reddit. Naukri. WellFound. You name it, I've already scrounged through it.

I also practiced DSA like there was no tomorrow. 4 problems every day. Couple that with spaced repetition and building projects, my schedule was packed tight.

When an opportunity comes in, GRAB it

I hate missing opportunities.

I now hate it even more, thanks to that exam day.

So when someone wrote a comment that his company was hiring for interns on a reddit post, I immediately reached out and asked for the details.

At that time, I had absolutely no idea where it would eventually lead.

The Assignment

"Oh nice, looks like this is a start-up", I thought and accepted the take-home assignment.

Out of curiosity, I decided to dig deeper into who assigned me the assignment. Turns out, he was a core contributor to one of the tools explicitly mentioned in the assignment.

I looked up the Reddit user whom I had contacted as well, and found that he held a senior position at the company.

That was the moment it hit me.

This wasn't just another take-home assignment I'd submit and forget about.

The people reviewing my code weren't just hiring managers. They had helped build the ecosystem I was now writing code for.

Suddenly, every line of code mattered. Every single decision I made mattered.

In short, I realized they weren't just looking for someone who could make the code work. They wanted someone who could think like an engineer.

Working on the assignment

I set up my repository and started building.

The assignment details were surprisingly good. Everything was moving smoothly.

Then came a major roadblock... where none of my solutions worked.

"Wtf do I even do?"

Eventually I reached out to the poster regarding the assignment.

Apparently, he expected candidates to ask questions instead of silently struggling. Now that was surprisingly refreshing.

I got the clarification, fixed the issue, and continued working and finally submitted it 2 days before the deadline.

The interview

I honestly didn't expect to reach the interview stage this quickly.

I prepared myself for the usual experience: formal introductions, rapid-fire technical questions, STAR format...

Instead, we spent time discussing Retrieval-Augmented Generation [RAG], projects, other tech stuff.

It felt less like being evaluated and more like talking to engineers who actually enjoyed engineering.

And soon...

An email landed in my inbox.

The internship offer letter. From the very US-based consultancy I talked about.

The month that started with my biggest academic disappointment ended with the opportunity I'd been chasing every single day.

If you're reading this after failing an exam...

You probably think you're behind.

You're not. You're just standing at a crossroads.

One road leads to endless doom-scrolling and self-pity. The other leads back to your desk.

Open your IDE.

Open LeetCode.

Ship something.

Apply again.

Because sometimes the worst day of your year quietly becomes the first chapter of your best story.

Mine started with failing NIMCET.

It led me to a US-based consultancy.

I can't wait to see where yours begins.

You receive an OTP via SMS, and your device suggests it automatically. One tap, and you're verified—no switching apps, no copying and pasting.

Now imagine the same seamless experience, but for email verification.

That's exactly what Google Chrome is working on with the Email Verification API, currently available as an Origin Trial.

The Problem with Email Verification

Today, verifying an email address usually looks like this:

1. Enter your email address.
2. Open your inbox.
3. Find the verification email.
4. Copy the OTP or click the verification link.
5. Return to the website.

It's a familiar process, but it breaks the user's flow.

Chrome's Proposal

Instead of relying on OTPs or verification links, Chrome wants browsers to verify ownership of an email address directly.

The flow looks like this:

1. You select an email address from the browser's autofill suggestions.
2. With your permission, the browser contacts the email provider.
3. The provider confirms that you own the selected email address.
4. The website receives the verification result.

No inbox.

No OTP.

No verification link.

Just a smoother user experience.

Why This Is Interesting

For users

• Faster sign-ups and logins
• No switching between the browser and email app
• Less friction during onboarding

For developers

• Simpler verification flows
• Fewer issues caused by delayed or missing emails
• Better conversion rates during registration

Current Status

The Email Verification API is currently available as an Origin Trial in Chrome. This allows developers to experiment with the feature and provide feedback before it becomes part of the web platform.

If adopted widely, email verification on the web could become as seamless as SMS OTP autofill is on modern smartphones.

Learn More

Read Google's announcement at their dev page

What do you think? Would you prefer this over traditional email verification links?

If you enjoyed this post, feel free to connect with me!

• X: @aiglelevant
• LinkedIn: Prajanya Subramanian
• Email: aiglelevant@gmail.com
• GitHub: @aigle-levant
• Substack: @aiglelevant
• Dev.to: Aiglelevant

I'd love to hear your thoughts or discuss all things web development, browsers and AI.