DEV Community: Sharath Kurup

Part 4: Improving Retrieval Quality with Token-Aware Chunking and HyDE

Sharath Kurup — Sun, 26 Apr 2026 03:04:50 +0000

Making RAG Smarter with Token-Aware Chunking, HyDE, and Context-Aware Search

In Part 3, we improved chunking and optimized context. The system was faster and cleaner… but still not always correct.

What broke after Part 3?

By this point, the system looked solid:

Smarter chunking
Context compression
FAISS + re-ranking
Streaming responses

But when I started using it more realistically, a few problems showed up:

1. Token limits were still hurting quality

Even with better chunks, we were still not controlling how much context we send to the model.

2. Vague queries failed badly

Questions like:

“Explain this”
“What does it mean?”

…would often retrieve irrelevant chunks.

3. Follow-up questions felt disconnected

The system didn’t “remember” what we were talking about.

At this point, it stopped feeling like a “retrieval problem”
…and more like a context understanding problem.

So in Part 4, I focused on making RAG smarter.

What we’re building in this part

Token-aware chunking (based on actual LLM limits)
HyDE (Hypothetical Document Embeddings)
Early version of context-aware retrieval

Updated Pipeline

Before jumping into code, here’s how the pipeline evolved:

Before (Part 3):

Query → Embedding → FAISS → Re-rank → Context → LLM

Now (Part 4):

Query → (HyDE) → Better Query → Embedding  
     → FAISS → Re-rank → Token-aware Context  
     → LLM (with constraints)

Problem 1: Token limits are real (and we were ignoring them)

Until now, chunking was based on:

characters
sentences
separators

But LLMs don’t think in characters.

They think in tokens.

Why this matters

You might send:

2 chunks → fine
5 chunks → maybe fine
10 chunks → silently truncated or degraded

And the worst part?

You won’t even know it’s happening.

Solution: Token-aware chunking

Instead of guessing chunk sizes, we measure them using a tokenizer.

import tiktoken

tokenizer = tiktoken.get_encoding("cl100k_base")

def get_token_length(text):
    return len(tokenizer.encode(text))

Now chunking becomes token-driven instead of size-driven.

Token-based chunking strategy

Key idea:

Build chunks until a token limit
If exceeded → split intelligently
Maintain overlap using tokens, not characters

MAX_TOKENS = 250
OVERLAP_TOKENS = 50

Smarter chunk building

Instead of blindly splitting:

Prefer paragraphs
Then sentences
Then fallback

def generate_chunks_recursive_tokens(text, page_num):
    paragraphs = text.split("\n\n")
    current_chunk = []
    current_tokens = 0

    for paragraph in paragraphs:
        paragraph_tokens = get_token_length(paragraph)

        if current_tokens + paragraph_tokens > MAX_TOKENS:
            chunks.append({
                "text": "\n\n".join(current_chunk),
                "page": page_num
            })

            current_chunk, current_tokens = _get_overlap(current_chunk)

        current_chunk.append(paragraph)
        current_tokens += paragraph_tokens

Why this works better

Matches actual LLM limits
Avoids hidden truncation
Improves context density
Makes responses more reliable

Problem 2: RAG fails on vague queries

This was the bigger issue.

Even with good chunking, queries like:

“Explain this concept”

…don’t contain enough semantic signal.

So FAISS retrieves something… but often not the right thing.

Solution: HyDE (Hypothetical Document Embeddings)

This is one of the most interesting tricks in RAG.

Instead of embedding the raw query…

👉 We first generate a hypothetical answer
👉 Then embed that

Why this works

A vague query becomes a rich semantic representation.

Example:

User query:

Explain this

HyDE generates:

This concept refers to a method where...

Now embedding this gives:

More keywords
Better semantic alignment
Stronger retrieval

Implementation

Step 1: Generate hypothetical answer

def generate_hypothetical_answer(query, chat_history):
    recent_user = [m["content"] for m in chat_history[-4:] if m["role"] == "user"]
    history_text = " | ".join(recent_user[-2:])

    prompt = (
        f"Write a 2-sentence technical summary answering: {query}\n"
        f"Recent user context: {history_text}"
    )

    response = ollama.generate(
        model=HYDE_MODEL,
        prompt=prompt,
        stream=False
    )

    return response['response']

Step 2: Augment the query

hypothetical_answer = generate_hypothetical_answer(query, chat_history)
search_query = f"{query} {hypothetical_answer}"

Step 3: Embed the enriched query

response = ollama.embed(model=EMBED_MODEL, input=search_query)

Impact

Better retrieval for vague queries
Improved relevance
More stable responses

At the cost of:

~1–2 seconds extra latency

Worth it? In most cases — yes.

Early Step: Context-aware retrieval

Another issue we started addressing:

Follow-up questions were treated as completely new queries.

Example:

User: Explain attention mechanism
User: How does it work?

Second query loses context.

What we added

A simple but effective improvement:

Detect vague follow-ups
Inject previous page context

if not target_page and vague_followups.match(query.strip()):
    last_pages = get_last_referenced_pages(chat_history)

    if last_pages:
        query = f"{query} page {last_pages[0]}"

Result

Follow-ups become meaningful
Retrieval stays anchored
Conversation feels connected

Putting it all together

Now the system:

Understands token limits
Improves weak queries
Handles basic conversation flow

From learning project → real system

This is where things started to change.

Earlier:

It worked
It demonstrated RAG

Now:

It behaves more like a real assistant
Handles imperfect queries
Works under constraints

What’s next?

We’ve improved:

Data representation (chunks)
Query understanding (HyDE)

But one big gap still remains:

We still don’t know why RAG fails when it fails.

In Part 5, we’ll go deeper into:

Debugging the RAG pipeline
Visualizing FAISS vs re-ranking
Understanding retrieval quality
Making the system more transparent

Code

Full implementation available here:

👉 https://github.com/SharathKurup/chatPDF/blob/token_aware_rag/

Final thoughts

At a high level, RAG seems simple:

Retrieve → augment → generate

But in practice, most of the work is here:

How you represent data
How you interpret queries
How you control context

This part was about tightening those pieces.

And it makes a noticeable difference.

If you’ve been building with RAG, I’d recommend trying:

Token-aware chunking
HyDE

They’re relatively small changes — but high impact.

Let me know what you think or what you’d improve.

Understanding RAG by Building a ChatPDF App: Smarter Chunking & Context Optimization (Part 3)

Sharath Kurup — Mon, 20 Apr 2026 06:55:25 +0000

⚡ Understanding RAG by Building a ChatPDF App: Better Chunking & Smarter Context

In Part 1, we made it work.
In Part 2, we made it fast.
In Part 3, things got… interesting 😅

📌 Recap from Part 1 & 2

In the previous parts:

👉 Part 1

Built a basic RAG pipeline using NumPy
Understood embeddings + similarity search

👉 Part 2

Switched to FAISS for fast retrieval ⚡
Added persistence + re-ranking

At this point, everything looked solid.

😅 But Something Still Felt Off

I started testing with real questions…

query = "What is FAISS indexing?"

And sometimes the answer would:

Talk about embeddings instead
Miss key details
Or feel… slightly off

🤔 The weird part?

The answer was actually present in the document.

But we weren’t retrieving the right chunk.

🧠 The Real Problem Was Not Search

FAISS was doing its job.

The issue was earlier in the pipeline:

We were feeding it bad chunks.

🔍 Let’s Look at the Old Chunking Logic

def generate_chunks(text, page_num):
    chunks = []
    i = 0
    while i < len(text):
        end = min(i + CHUNK_SIZE, len(text))
        chunk = text[i:end]

        if end < len(text):
            last_space = chunk.rfind(" ")
            if last_space != -1:
                end = i + last_space
                chunk = text[i:end]

        chunks.append({"text": chunk, "page": page_num})
        i = end - OVERLAP_SIZE

🧠 What This Was Doing

Split text using fixed size
Avoid breaking words
Add overlap

Looks reasonable… right?

🚨 Where It Breaks

Let’s take a simple example:

Original:
"FAISS is a library for efficient similarity search. It is widely used in RAG systems."

Now imagine this gets chunked like:

Chunk 1:
"FAISS is a library for efficient similarity"

Chunk 2:
"search. It is widely used in RAG systems"

💥 What just happened?

The sentence got split
Meaning got split
Embeddings lost context

Embeddings don’t understand fragments
They understand complete ideas

🔍 Let’s Visualize This

Let’s visualize what was actually happening 👇

👉 Notice how sentences are broken across chunks —
this is exactly what degrades retrieval quality.

💡 The Shift in Thinking

Instead of:

“Split text by size”

We need:

“Split text by meaning”

🚀 Step 1: Recursive Chunking (Respect Structure)

✅ New Approach

def generate_chunks_recursive(text, page_num, chunk_size, overlap_size):
    chunks = []
    start = 0

    while start < len(text):
        end = start + chunk_size
        chunk_slice = text[start:end]

        for separator in ["\n\n", "\n", ". ", " "]:
            last_break = chunk_slice.rfind(separator)
            if last_break != -1:
                if separator == ". ":
                    last_break += 1
                break
        else:
            last_break = chunk_size

        actual_end = start + last_break
        final_chunk = text[start:actual_end].strip()

        chunks.append({"text": final_chunk, "page": page_num})
        start = actual_end - overlap_size

🧠 What Changed Here?

Instead of blindly splitting, we now:

for separator in ["\n\n", "\n", ". ", " "]:

We try:

Paragraph
Line
Sentence
Word

👉 This is a priority-based splitting strategy

💡 Why This Works Better

Paragraphs stay intact
Sentences stay intact
Meaning stays intact

✅ Micro Summary

What changed: Structure-aware chunking
Why it matters: Better embeddings → better retrieval

🔁 Step 2: Overlap Still Matters

We still keep overlap:

[Chunk 1]  "RAG systems work by retrieving relevant context"
[Chunk 2]         "retrieving relevant context from documents"

🧠 Why This Is Important

Prevents context gaps
Keeps continuity between chunks

🔥 Step 3: Storing Full Context (Big Upgrade)

def generate_advanced_chunks(page_content, page_num):
    search_chunks = generate_chunks_recursive(...)

    for chunk in search_chunks:
        chunk["text"] = f"[Page {page_num}] {chunk['text']}"
        chunk["full_context"] = page_content

🧠 Why This Matters

Earlier:

👉 We only stored chunk text

Now:

👉 We also store the entire page

💡 What This Enables

Better answer generation
Flexibility for later processing
Smarter context selection

🚨 New Problem Introduced

Now that we store full pages…

We started sending too much data to the LLM.

❌ Problem

Large token usage
Slower responses
Irrelevant information

🚀 Step 4: Context Compression

def compress_context(query, full_text):
    sentences = re.split(r'(?<=[.!?]) +', full_text)
    query_words = set(query.lower().split())

    scored_sentences = []
    for s in sentences:
        score = sum(1 for word in s.lower().split() if word in query_words)
        scored_sentences.append((score, s))

    top_sentences = sorted(scored_sentences, key=lambda x: x[0], reverse=True)[:MAX_SENTENCES]
    return " ".join([s for _, s in top_sentences])

🧠 What’s Happening Here?

Break into sentences
Score relevance using query
Keep only top sentences

🔍 Visualize It

Before:
Full page → 1000+ tokens ❌

After:
Relevant sentences → smaller context ✅

💡 Why This Is Powerful

Faster responses
Better relevance
Lower token usage

✅ Micro Summary

What changed: Context filtering
Why it matters: Less noise → better answers

🔍 Retrieval Still Uses FAISS + Re-ranking

distances, indices = index.search(query_vector.reshape(1,-1), k=10)
results = ranker.rerank(rerank_request)

🧠 Flow

FAISS → fast retrieval
Re-ranker → improves relevance
Top results → passed to LLM

💬 Smarter Answer Generation

compressed_text = compress_context(query, res['full_context'])

👉 Instead of raw chunks, we now send:

Focused, relevant context

🔁 Final System

🧠 What Changed Overall

Feature	Part 1	Part 2	Part 3
Search	NumPy	FAISS	FAISS + Rerank
Chunking	Basic	Basic	Recursive 🧠
Context	Raw	Raw	Compressed 🔥
Accuracy	Low	Medium	High

🧠 Final Thought

This is where things clicked for me.

I kept thinking better models would fix my system…

But the real issue was:

Bad context in → bad answers out

Most people focus on:

Models ❌
Vector DB ❌

But the real gains came from:

👉 Chunking
👉 Context handling

🔜 What’s Next?

Now things get even more interesting.

In Part 4:

👉 We’ll move beyond basic retrieval and make the system smarter

Token-aware chunking
Better query understanding
More intelligent retrieval

💬 Let’s Connect

If you're building something similar or experimenting with local LLMs, I’d love to hear your thoughts 👇

Understanding RAG by Building a ChatPDF App: From NumPy to FAISS (Part 2)

Sharath Kurup — Tue, 14 Apr 2026 06:44:11 +0000

⚡ From NumPy to FAISS: Making ChatPDF Fast & Scalable

In Part 1, we made it work.
In Part 2, we make it usable 🚀

📌 Recap from Part 1

In Part 1, we built a ChatPDF app using:

PDF → Text → Chunks
Embeddings using Ollama
Similarity search using NumPy
LLM to generate answers

It worked well for small PDFs and helped us understand RAG from first principles.

But once I started testing with slightly larger PDFs…

😅 The Problem Started Showing Up

The issue was not correctness — it was performance.

Let’s revisit what we were doing during search.

❌ NumPy Search (What we had before)

similarities = np.dot(vector_db, query_vector)
top_indices = np.argsort(similarities)[-TOP_K:][::-1]

🧠 What’s actually happening here?

Every time you ask a question:

Compute similarity with every chunk
Store all similarity scores
Sort the entire list
Pick top K

🚨 Why this becomes a problem

Time complexity → O(n) per query
More chunks = slower search
Entire dataset scanned every time

To make this visible, I added timing:

start_time = time.perf_counter()
# similarity logic
end_time = time.perf_counter()
print(f"Total time with numpy: {execution_time}")

And as the number of chunks increased…
⏳ the delay became noticeable.

💡 So What’s the Solution?

Instead of:

“Search through everything every time”

We need:

“A system that knows where to look”

🔍 Let’s Visualize the Problem (This is the key moment)

👉 This is where the real difference becomes obvious:

💡 What this diagram shows:

NumPy → scans every single chunk
FAISS → directly jumps to the most relevant results

This is the exact shift from:

brute force → intelligent retrieval

🚀 Introducing FAISS

FAISS (Facebook AI Similarity Search) is built for:

Fast vector similarity search
Efficient indexing
Handling large datasets

The key idea:

👉 Build an index once → search efficiently many times

🔄 Step 1: Moving from Raw Vectors → FAISS Index

❌ Before (NumPy mindset)

We stored vectors like this:

vector_db = np.array(vectors, dtype=np.float32)

That’s it.

No structure. No optimization. Just raw data.

✅ After (FAISS approach)

vector_np = np.array(vectors).astype('float32')

dimension = vector_np.shape[1]
index = faiss.IndexFlatIP(dimension)
index.add(vector_np)

🧠 Let’s understand this properly

1️⃣ Converting to float32

vector_np = np.array(vectors).astype('float32')

FAISS requires vectors in float32.

Even if your embeddings are already floats, doing this ensures:

Compatibility
No runtime surprises

2️⃣ Getting the dimension

dimension = vector_np.shape[1]

Each embedding looks like:

[0.12, -0.45, 0.88, ...]

The number of elements = dimension

FAISS needs this to build the index correctly.

3️⃣ Creating the index

index = faiss.IndexFlatIP(dimension)

IndexFlatIP → Inner Product search
Since embeddings are normalized → 👉 Inner Product ≈ Cosine Similarity

So we are essentially saying:

“Store these vectors and allow fast similarity-based search.”

4️⃣ Adding vectors to FAISS

index.add(vector_np)

This step:

Loads all embeddings into FAISS
Builds the internal structure

👉 From here, we stop thinking in terms of arrays and start thinking in terms of an index

🎯 Big Concept Shift

NumPy	FAISS
Raw vectors	Indexed vectors
Manual search	Optimized search
Full scan	Smart retrieval

🔍 Step 2: Searching with FAISS

❌ Before (NumPy)

similarities = np.dot(vector_db, query_vector)
top_indices = np.argsort(similarities)[-TOP_K:][::-1]

✅ After (FAISS)

distances, indices = index.search(query_vector.reshape(1, -1), k=TOP_K)

🧠 Let’s break this down

1️⃣ Why reshape?

query_vector.reshape(1, -1)

FAISS expects:

[number_of_queries, dimension]

Even a single query must be shaped like:

[[embedding]]

2️⃣ What does `search()` do?

distances, indices = index.search(...)

FAISS:

Finds nearest vectors
Sorts internally
Returns top K

3️⃣ Mapping results back

[text_metadata[i] for i in indices[0]]

We use indices to fetch:

Actual text chunks
Page numbers

💡 Why this is powerful

Instead of:

Writing similarity logic ❌
Writing sorting logic ❌

You now:

👉 Call one optimized function

💾 Step 3: Avoid Recomputing Everything

🚨 Problem in Part 1

Every run:

Read PDF
Chunk text
Generate embeddings
Build vectors

✅ Solution: Save the Index

faiss.write_index(index, "db/index.faiss")

with open("db/metadata.pkl", "wb") as f:
    pickle.dump(data, f)

🧠 What are we saving?

FAISS index → vector structure
Metadata → chunk + page info
PDF hash → detect changes

🔁 Loading instead of recomputing

index = faiss.read_index("db/index.faiss")

Now:

⚡ Faster startup
❌ No repeated embedding calls

🔐 Step 4: Detecting PDF Changes

def calculate_pdf_hash():
    sha256_hash = hashlib.sha256()

🧠 Why this matters

If the PDF changes:

Old embeddings become invalid

So we:

Generate hash
Compare with stored hash
Rebuild only if needed

👉 Small addition, big impact.

🔥 Step 5: Improving Retrieval with Re-ranking

Even FAISS isn’t perfect.

So we add another layer:

results = ranker.rerank(rerank_request)

🧠 What’s happening here?

FAISS retrieves top 10 chunks
Re-ranker evaluates relevance
Returns best TOP_K

📊 Debug visibility

print("--- Re-ranker Scores ---")

Helps you:

Understand ranking
Debug results

💬 Step 6: Streaming Responses (UX Upgrade)

for chunk in generate_answer(user_query, context_llm):
    print(chunk['response'], end='', flush=True)

🧠 Why this matters

Feels real-time
Improves perceived speed
Better experience

🔁 Final System (Let’s Visualize It)

👉 This is what your ChatPDF system looks like now:

🧠 What this diagram represents

Query → converted into embedding
FAISS → retrieves relevant chunks
Re-ranker → improves quality
LLM → generates final answer

👉 This is a complete RAG pipeline

🚀 What We Achieved

Feature	Part 1 (NumPy)	Part 2 (FAISS)
Search	Brute force	Indexed ⚡
Speed	Slow	Fast
Persistence	❌	✅
Accuracy	Basic	Improved
UX	Basic	Streaming

🧠 Final Thoughts

This is where things became real.

From “I understand RAG”
to
“I can build something scalable”

If you’re learning RAG:

Start with NumPy ✅
Move to FAISS ✅

That transition is where the real understanding happens.

📂 Project Repo

👉 https://github.com/SharathKurup/chatPDF/tree/faiss_indexing

🔜 What’s Next?

In Part 3:

👉 We’ll build a Streamlit UI
👉 Turn this into a proper app

💬 Let’s Connect

If you're building something similar or exploring local LLMs, I’d love to hear your thoughts 👇

Understanding RAG by Building a ChatPDF App with NumPy (Part 1)

Sharath Kurup — Wed, 08 Apr 2026 02:21:07 +0000

🧠 Building a Chat with PDF App (From Scratch using NumPy)

Turning a simple PDF into a conversational AI system using local LLMs 🚀

📌 Introduction

Have you ever wanted to chat with your PDF documents like you chat with ChatGPT?

In this series, I’ll walk you through building a ChatPDF application from scratch, starting from the absolute basics and gradually improving it into a production-ready system.

👉 In this first part, we’ll build a naive RAG (Retrieval-Augmented Generation) system using only NumPy — no FAISS, no vector databases, just pure fundamentals.

🎯 What We’ll Build

By the end of this article, you’ll have:

📄 A system that reads a PDF
✂️ Splits it into meaningful chunks
🔢 Converts text into embeddings using a local model
🔍 Searches relevant content using vector similarity
💬 Generates answers using an LLM

⚙️ Tech Stack

pdfplumber → Extract text from PDFs
numpy → Perform vector similarity search
ollama → Run local embedding + LLM models

🧩 How It Works (High Level)

Our pipeline looks like this:

PDF → Text → Chunks → Embeddings → Similarity Search → LLM → Answer

📥 Step 1: Reading the PDF

We start by extracting text page by page:

def readpdf():
    all_texts = []
    with pdfplumber.open(PDF_PATH) as pdf:
        for i, page in enumerate(pdf.pages):
            text = page.extract_text() or ""
            if not text.strip():
                continue
            all_texts.append((i + 1, text))
    return all_texts

🧠 What’s happening?

Reads each page
Skips empty pages
Stores (page_number, text)

✂️ Step 2: Chunking the Text

Large text doesn’t work well for embeddings or LLMs, so we split it:

def generate_chunks(text, page_num):
    chunks = []
    i = 0
    while i < len(text):
        end = min(i + CHUNK_SIZE, len(text))
        chunk = text[i:end]

        if end < len(text):
            last_space = chunk.rfind(" ")
            if last_space != -1:
                end = i + last_space
                chunk = text[i:end]

        chunks.append({"text": chunk.strip(), "page": page_num})

        i = end - OVERLAP_SIZE

🧠 Why overlap?

Prevents context loss between chunks
Helps LLM understand continuity

🔢 Step 3: Generating Embeddings

We convert text into vectors using Ollama:

def generate_embeddings_batch(texts):
    all_embeddings = []
    for i in range(0, len(texts), BATCH_SIZE):
        batch_texts = texts[i:i+BATCH_SIZE]
        response = ollama.embed(model=EMBED_MODEL, input=batch_texts)
        all_embeddings.extend(response["embeddings"])
    return all_embeddings

🧠 Why batching?

Faster processing
Efficient use of resources

📏 Step 4: Similarity Search (Core Logic)

Here’s where NumPy shines:

similarities = np.dot(vector_db, query_vector)
top_indices = np.argsort(similarities)[-TOP_K:][::-1]

🧠 What’s happening?

We compute dot product similarity
Higher score = more relevant chunk
Select top K results

👉 This is essentially a manual vector database using NumPy

💬 Step 5: Generate Answer using LLM

We pass retrieved chunks as context:

def generate_answer(query, chunks):
    context_chunks = "\n\n".join(chunks)
    prompt = f"""
Context:
{context_chunks}

Question:
{query}

Answer:
"""
    response = ollama.generate(model=THINKING_MODEL, prompt=prompt)
    return response["response"]

🧠 Key Idea

We’re doing RAG (Retrieval-Augmented Generation):

Retrieval → relevant chunks
Generation → LLM response

🔁 Step 6: Interactive Chat Loop

def chat_pdf(vector_db, text_metadata):
    while True:
        user_query = input("You - ")
        results = search(user_query, vector_db, text_metadata)

        context_llm = [res["text"] for res in results]
        response = generate_answer(user_query, context_llm)

        print(response)

Now you can literally:

You - What is the main topic?
AI  - ...

🔍 Bonus: Embedding Normalization Check

norms = np.linalg.norm(embeddings_array, axis=1)

🧠 Why this matters?

If vectors are normalized → dot product ≈ cosine similarity
Improves consistency in search results

🚨 Limitations of This Approach

This implementation is intentionally simple — and that comes with trade-offs:

⚠️ 1. Slow Search for Large PDFs

NumPy scans every vector
No indexing → O(n) search

⚠️ 2. Not Scalable

Works fine for small docs
Breaks down with:
- Large PDFs
- Multiple documents

⚠️ 3. No Persistent Storage

Embeddings are generated every run
No caching or database

⚠️ 4. Limited Retrieval Quality

Pure similarity search
No reranking, filtering, or hybrid search

⚠️ 5. Context Limitation

Only TOP_K chunks used
May miss important information

🧠 What You Learned

How RAG works under the hood
How embeddings enable semantic search
How to build a vector search using NumPy
How LLMs use context to answer questions

🔜 What’s Next?

In Part 2, we’ll upgrade this system by replacing NumPy search with:

➡️ FAISS (Facebook AI Similarity Search)

This will give us:

⚡ Faster retrieval
📈 Better scalability
🧠 Efficient indexing

📂 Project Repo

👉 GitHub: https://github.com/SharathKurup/chatPDF/tree/numpy_vector

💬 Final Thoughts

This is the most important step in understanding RAG systems:

Before using fancy tools like FAISS or vector DBs,
you should understand what’s happening underneath.

Once you get this, everything else becomes easy.

If you're building something similar or experimenting with local LLMs, I’d love to hear your thoughts 👇

Stay tuned for Part 2 🚀