DEV Community: Sabi Mantock

Learning LangChain

Sabi Mantock — Mon, 12 Oct 2026 17:44:01 +0000

A while back I built Synapse, a small app that answers questions using my own notes. I did every part of it by hand: load the files, turn them into vectors, find the closest ones to the question, and hand those to an LLM. It worked, and I understood it, because I'd written every line myself.

So when I started LangChain, a framework that promised to do all of that for me felt a little suspicious. My honest question was: what is this doing that I haven't already done?

It turns out the answer is less "new ideas" and more "a standard shape for the ones you already have." Let me walk through it the way I learned it.

Start small: messages and templates

A chat model doesn't take one big string. It takes a list of messages: a system message that sets the role, then human messages from you, then AI messages from the model. LangChain gives each of those its own class. Nothing magic, it's the same thing the raw API wants.

Prompt templates were the next small step. Instead of building a string every time, you write the prompt once with a gap in it:

from langchain_core.prompts import ChatPromptTemplate

template = ChatPromptTemplate.from_template(
    "I've recently adopted a {pet}. Suggest three {pet} names."
)

Then an output parser takes the model's text reply and turns it into something you can actually use, like a Python list. The thing that stuck with me here is that the parser is only as good as your instructions. Vague instructions about the format gave me a messy list. Strict ones gave me a clean one.

The pipe

This is the bit where it clicked for me. LangChain lets you join those pieces with a |, like a Unix pipe:

chain = chat_template | chat | list_output_parser
chain.invoke({"pet": "dog"})
# ['Max', 'Bella', 'Luna']

A prompt goes in one end, the model sits in the middle, and a clean list comes out the other end. Each step's output is the next step's input. That's the whole idea.

It even works for ordinary Python functions. Wrap them in RunnableLambda and they snap in like any other piece:

from langchain_core.runnables import RunnableLambda

add_up = RunnableLambda(lambda x: sum(x))
square = RunnableLambda(lambda x: x**2)

(add_up | square).invoke([1, 2, 5])   # 8, then 64

You can also draw a chain. chain.get_graph().print_ascii() prints the boxes and arrows, which is surprisingly handy when a chain gets long.

Two more things I liked. RunnableParallel runs two chains side by side and gives both results to the next step. And batch is quicker than looping: two requests through batch took 2.67 seconds in my notebook, while the same two as separate calls took about 7.5.

Now RAG, with the same pieces

Remember my five hand-built steps? LangChain has a piece for each.

For loading, there are loaders for different file types. I used one for PDFs and one for Word documents. Splitting was the new part, since Synapse never did any. I split a six-page document twice. First by its headings, so every chunk remembers which lecture it came from, then by size, about 500 characters with a little overlap. That left me with 20 chunks, each labelled with where it came from.

Each chunk then became 1,536 numbers using OpenAI's embedding model. I wanted to see if it really worked, so I compared three pairs of chunks. They scored 0.88, 0.80 and 0.79, so related text does end up close together. The vectors all have a length of about 1, which is why a plain dot product works as a similarity score.

Those vectors went into Chroma, which saves them to a folder on disk so I don't have to re-embed every time I open the notebook.

Retrieval comes in two flavours. A plain similarity search gives you the closest chunks. MMR gives you close chunks that are also different from each other, so you don't get five copies of the same paragraph.

And the last step is where the pipe comes back. The whole thing is one chain:

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt_template
    | chat
    | StrOutputParser()
)

chain.invoke("What software do data scientists use?")

The retriever fills in the context, the question passes straight through, the prompt tells the model to answer only from that context and name the lecture it used, and the parser hands back plain text. The answer ended with:

Resources: Programming Languages & Software Employed in Data Science - All the Tools You Need

That's the same "only use these notes" guard I wrote by hand in Synapse, plus the sources I'd been putting off adding.

What this changed for me

LangChain didn't teach me a new idea. Everything in that pipeline is something I'd already done by hand: load, embed, find the closest, ask. What it gave me was a standard shape for each step, and the pipe to join them. Having built it the long way first is what made the short way make sense.

Next up is LangGraph.

Going Back to TypeScript Basics

Sabi Mantock — Sat, 26 Sep 2026 09:13:41 +0000

After finishing my JavaScript refresher, TypeScript was next.

I’ve used TypeScript before, so I went into this thinking it would mostly be a case of reminding myself of things I already knew.

That was partly true.

The basic stuff came back pretty quickly. Types on variables, functions, arrays, objects — nothing too surprising there.

const memberCount: number = 10;

function isAdmin(role: string): boolean {
    return role === "admin";
}

But as I went further, I started noticing the same thing that happened during my JavaScript refresher.

There’s a difference between recognising something and actually understanding it.

I could look at a generic and think, yeah, I know what that is. But could I write one myself? Could I explain why I needed it? Could I tell when I didn't need one?

Not always.

And that’s really why I wanted to do this refresher in the first place.

TypeScript started making more sense when I stopped fighting it

One thing that became clearer this time was type narrowing.

Say I have:

interface Member {
    name: string;
    profilePicture: string | null;
}

I can't just do:

member.profilePicture.toUpperCase();

because TypeScript doesn't know whether profilePicture is actually a string.

My first instinct in the past would've probably been something along the lines of, I know it's a string here, why are you complaining?

But that's the point.

I might know what I expect the value to be. TypeScript wants me to prove it.

if (member.profilePicture !== null) {
    member.profilePicture.toUpperCase();
}

Once I started looking at narrowing like that, it stopped feeling like TypeScript getting in my way.

The same thing happened with .find().

function findMember(
    members: Member[],
    name: string
): Member | undefined {
    return members.find((member) => member.name === name);
}

I might expect the member to exist, but .find() doesn't care about my expectations. It can return undefined.

So the type should say that.

Simple, but important.

Generics weren't as scary as they looked

Generics were another one.

This:

function getLast<T>(items: T[]): T | undefined {
    return items[items.length - 1];
}

used to look more complicated than it actually is.

Once I started thinking of T as basically saying “whatever type you give me”, it became much easier to read.

Give it strings?

T is a string.

Give it numbers?

T is a number.

Give it members?

T is a Member.

Then we got to things like:

function getPostValue<K extends keyof Post>(
    post: Post,
    key: K
): Post[K] {
    return post[key];
}

Now, I'll admit, something like this still looks a bit mad when you first see it.

But breaking it apart helped.

keyof Post gives me the valid keys from Post.

K is one of those keys.

Post[K] is the type of whatever property I asked for.

So if "title" points to a string, TypeScript knows I'm getting a string back. If "likes" points to a number, I get a number.

It wasn't really about memorising the syntax. It was understanding what each part was trying to describe.

I managed to confuse Pick and Omit

We also went through TypeScript's utility types: Partial, Pick, Omit and Record.

Most of it was straightforward.

Then I got asked something like:

If you only want title, company and salary from a Job type, which utility type would you use?

I said Omit.

My reasoning?

Because I only wanted title, company and salary.

Which is literally the reason I should have used Pick.

😂

That mistake actually made the difference easier to remember than just reading the documentation would have.

Pick what you want to keep.

Omit what you want to remove.

Sometimes getting something wrong once is all it takes.

Then things started connecting

Discriminated unions were where TypeScript started feeling less like “adding types to JavaScript” and more like actually modelling how an application works.

For example:

type MemberState =
    | { status: "loading" }
    | { status: "success"; members: Member[] }
    | { status: "error"; message: string };

If the status is "success", TypeScript knows there are members.

if (state.status === "success") {
    console.log(state.members);
}

If it's "error", TypeScript knows there's a message.

And if it's "loading", neither of those things should exist yet.

That makes sense because that's how the application actually behaves.

We also looked at never for checking that every possible state has been handled.

That was when I started seeing that a lot of these TypeScript features aren't really separate things.

They build on each other.

Union types lead to narrowing.

Narrowing makes discriminated unions useful.

Discriminated unions make exhaustive checking possible.

The individual syntax started mattering less than the relationship between everything.

Type predicates were another good example

We wrote things like:

function isAdmin(user: User): user is Admin {
    return user.role === "admin";
}

The interesting bit for me was:

user is Admin

We're not just returning true or false.

We're telling TypeScript:

If this function returns true, I've checked this value and you can treat it as an Admin.

That's powerful, but there's also a catch.

TypeScript trusts you.

If the function says user is Admin but my actual logic checks for a member instead, TypeScript isn't going to magically save me.

I'd basically be lying to the compiler.

That distinction between what TypeScript can check and what my code still needs to get right came up again later.

API data made `unknown` click for me

This was probably one of the most useful parts of the refresher.

Imagine I do this:

const data: Member[] = await response.json();

It looks nice.

My editor is happy.

TypeScript thinks I have an array of members.

But what if the API sends something completely different?

Writing Member[] doesn't magically transform the response into valid member data.

I'm basically just telling TypeScript to trust me.

A safer starting point is:

const data: unknown = await response.json();

Now I have to prove what the data actually is before using it.

We ended up building a validator manually:

function isMember(value: unknown): value is Member {
    if (typeof value !== "object" || value === null) {
        return false;
    }

    if (!("name" in value) || typeof value.name !== "string") {
        return false;
    }

    if (!("id" in value) || typeof value.id !== "number") {
        return false;
    }

    if (
        !("role" in value) ||
        (value.role !== "admin" && value.role !== "member")
    ) {
        return false;
    }

    if (
        !("isOnline" in value) ||
        typeof value.isOnline !== "boolean"
    ) {
        return false;
    }

    return true;
}

And, of course, I got some of the logic wrong at first.

I was doing something similar to:

if (("id" in value) && typeof value.id === "number") {
    return true;
}

In my head I was checking that the id was valid.

Which I was.

The problem was that I was then returning true for the entire object.

So apparently having a valid ID was enough to become a valid member. Name? Role? Online status?

Who needs those? 😂

The better way was:

if (!("id" in value) || typeof value.id !== "number") {
    return false;
}

Check each reason the object could be invalid, reject it when something is wrong, and only return true once it survives all the checks.

That wasn't even really a TypeScript problem.

It was a logic problem.

And that's exactly the kind of thing I wanted this refresher to expose.

By the end, the types were doing something useful

Towards the end, I had to model members and admins.

My first attempt was:

type Role = "admin" | "member";

interface Member {
    id: number;
    name: string;
    role: Role;
    isOnline: boolean;
}

interface Admin extends Member {
    permissions: string[];
}

Looks reasonable.

Except there's a problem.

Because Admin inherits role: Role, this is technically possible:

const admin: Admin = {
    id: 1,
    name: "Sabi",
    role: "member",
    isOnline: true,
    permissions: ["delete-post"]
};

An admin whose role is "member".

Not exactly ideal.

So we changed the model:

interface BaseUser {
    id: number;
    name: string;
    isOnline: boolean;
}

interface Member extends BaseUser {
    role: "member";
}

interface Admin extends BaseUser {
    role: "admin";
    permissions: string[];
}

type User = Member | Admin;

Now an Admin has to be an admin.

A Member has to be a member.

Then I could write:

function getOnlineAdmins(users: User[]): Admin[] {
    return users.filter(
        (user) => user.role === "admin" && user.isOnline
    );
}

It's a small example, but I think it sums up what I've taken from this refresher.

Before, I probably would have looked at TypeScript mainly as a way of saying:

name: string
age: number
isOnline: boolean

That's part of it.

But good types can describe much more than that.

They can describe what states are possible, what data might be missing, what kind of user you're dealing with, what a function actually returns and what your application should and shouldn't allow.

So, do I know TypeScript now?

More than I did before.

Everything? Definitely not.

There are still advanced parts of TypeScript that I haven't touched, and I'm sure I'll run into plenty of things that make me stare at my screen wondering what on earth I'm looking at.

But I don't think I need to know all of TypeScript before moving forward.

That wasn't the point.

The point was to get comfortable enough with the fundamentals that when I start using TypeScript properly with React, I'm not just adding types until the red lines disappear.

More importantly, I'm starting to understand what TypeScript is trying to tell me when those red lines appear.

JavaScript refresher done.

TypeScript refresher done.

Now, React.

The Joy of Learning the Basics Again

Sabi Mantock — Tue, 22 Sep 2026 01:28:19 +0000

I’ve been revisiting JavaScript recently.

Not because I’ve never used it before, but because I realised there were a lot of things I could recognise when I saw them in code without feeling fully confident that I understood them properly.

That distinction started bothering me.

I could read JavaScript.

I could follow what was happening.

But being able to look at code and understand it is not always the same as being able to sit down with a blank file and write it confidently yourself.

So I decided to go back to the basics.

And weirdly enough, I’ve been enjoying it a lot more than I expected.

There’s something satisfying about revisiting something familiar and realising you understand it differently the second time around.

Starting from the beginning again

I started with things like:

const userName = "Sabi";
const role = "admin";
let postCount = 0;

Very basic stuff.

At first, part of me wanted to rush through it because I already knew what const and let were.

But slowing down actually helped.

Instead of just remembering that let can be reassigned and const cannot, I started thinking more deliberately about why I would choose one over the other.

That set the tone for the rest of the refresher.

I wasn’t just trying to remember syntax.

I wanted the concepts to actually make sense.

Functions exposed a few gaps

Functions were another area where I thought I was already comfortable.

Then I started paying more attention to the smaller details.

For example:

function checkAccess(role) {
    return role === "admin";
}

checkAccess("admin");

role is the parameter.

"admin" is the argument.

Simple distinction, but it reminded me how easy it is to skip over small concepts because you’ve seen them so many times.

Those gaps add up.

Arrays were where things started getting more interesting

I revisited arrays and loops, then moved into:

map()
filter()
find()
some()
every()
reduce()

These are methods I’ve seen and used before, but going through them one by one made the differences much clearer.

For example:

const users = [
    { name: "Sabi", role: "admin" },
    { name: "Kong", role: "member" },
    { name: "Vandal", role: "member" }
];

To get all admins:

const admins = users.filter(
    (user) => user.role === "admin"
);

To get one particular user:

const user = users.find(
    (user) => user.name === "Vandal"
);

Same array.

Different intention.

That sounds obvious, but writing these things myself made them stick much better than just reading examples.

I had been using callbacks without really thinking about them

This was one of the more useful moments.

Something like:

users.filter((user) => user.role === "admin");

looks completely normal.

But that function inside filter() is a callback.

When I recreated the idea manually:

function welcomeUser(name) {
    console.log(`Welcome, ${name}`);
}

function welcomeUsers(users, callback) {
    for (let i = 0; i < users.length; i++) {
        callback(users[i]);
    }
}

it clicked more clearly.

A callback stopped sounding like some special JavaScript concept.

It was just a function being passed into another function so it could be called later.

Sometimes understanding something is really just removing the fancy name from it.

Destructuring finally stopped feeling like magic

I’ve used destructuring plenty of times before:

const { name, role } = user;

and:

const [firstUser, secondUser] = users;

But during the refresher, I actually made a mistake and tried to destructure an array using {}.

That was useful.

It forced me to think about what JavaScript was actually doing.

Objects:

const { name, role } = user;

Arrays:

const [firstUser, secondUser] = users;

Objects are matched by property name.

Arrays are matched by position.

That mistake probably taught me more than just reading the correct syntax would have.

Spread and rest made more sense this time

Then came spread:

const updatedUsers = [...users, "Efo"];

and:

const updatedUser = {
    ...user,
    role: "admin"
};

I’d seen this syntax countless times before.

But revisiting it properly made the logic much clearer.

Spread takes existing values and spreads them into a new structure.

Rest uses the same ... but collects values:

function addUsers(...users) {
    return users;
}

The way I remember it now is:

Spread = spread things out

Rest = gather things together

Simple, but it works.

Async JavaScript was probably the most important part

Promises and async/await were where the refresher became much more valuable.

I created a Promise like this:

const getUsers = new Promise((resolve, reject) => {
    setTimeout(() => {
        resolve([
            { name: "Sabi", role: "admin" },
            { name: "Kong", role: "member" }
        ]);
    }, 5000);
});

Then worked with .then():

getUsers
    .then((users) => {
        return users.filter(
            (user) => user.role === "member"
        );
    })
    .then((members) => {
        return members.map(
            (member) => member.name
        );
    })
    .then((names) => {
        console.log(names);
    });

One thing that stood out here was the difference between logging and returning.

This:

console.log(users);

shows me something.

This:

return users;

passes the value forward so another part of the program can use it.

I knew that already in isolation, but Promise chaining made the difference feel much more important.

`async/await` made everything easier to reason about

Once I moved from .then() to:

async function showUsers() {
    try {
        const users = await getUsers;

        const members = users.filter(
            (user) => user.role === "member"
        );

        const names = members.map(
            (member) => member.name
        );

        console.log(names);
    } catch (error) {
        console.log(error.message);
    }
}

the flow became much easier to read.

I also finally got a stronger understanding of what await actually does.

It pauses the current async function.

It does not pause the entire JavaScript program.

That distinction made async code feel a lot less mysterious.

Fetch tied everything together

Then I moved into fetch().

const response = await fetch(
    "https://jsonplaceholder.typicode.com/users"
);

if (!response.ok) {
    throw new Error("Failed to fetch users");
}

const users = await response.json();

This was probably the point where the refresher stopped feeling like a list of separate JavaScript topics.

Suddenly everything connected:

functions
↓
Promises
↓
async/await
↓
HTTP
↓
fetch
↓
JSON
↓
arrays
↓
map / filter / find

That was one of the biggest things I took away from the whole process.

The concepts make much more sense when they stop being separate chapters and start working together.

Modules were a good place to finish

The final part of the refresher was modules.

I practised exporting functions:

export function findUser(users, name) {
    return users.find(
        (user) => user.name === name
    );
}

export function getAdmins(users) {
    return users.filter(
        (user) => user.role === "admin"
    );
}

and importing them somewhere else:

import {
    findUser,
    getAdmins
} from "./users.js";

I also revisited the difference between named exports and default exports.

Named:

export function findUser() {}

import { findUser } from "./users.js";

Default:

export default function UserProfile() {}

import UserProfile from "./UserProfile.js";

This is something I’ve seen constantly in modern JavaScript code, but going back to the fundamentals made it feel much less like framework magic.

The main thing I realised

The biggest takeaway from this refresher wasn’t any one JavaScript feature.

It was realising how easy it is to confuse familiarity with understanding.

You can see something a hundred times and still have gaps.

You can recognise code without being able to write it confidently.

You can use a pattern without fully understanding why it works.

That was the whole reason I went back.

Not to become a JavaScript expert before moving on.

Just to make the foundation stronger.

And somewhere along the way, I started enjoying the process more than I expected.

There’s a different kind of confidence that comes from understanding the basics properly.

Not the confidence of knowing everything.

Just the confidence of knowing what you’re standing on.

So far I’ve revisited:

variables and data types
operators and conditionals
functions and scope
arrays and loops
map, filter, find, some, every and reduce
objects
destructuring
spread and rest
callbacks
error handling
Promises
async/await
HTTP and fetch
modules

And I actually feel better for slowing down.

Next for me is TypeScript.

But this time, I’m moving forward with a much clearer understanding of the JavaScript underneath it.

Sometimes going back isn’t really going backwards.

Sometimes it’s just the fastest way to stop building on shaky ground.

From "I Understood Nothing" to Building a RAG App

Sabi Mantock — Tue, 16 Jun 2026 13:49:03 +0000

Yesterday, I took the time to go through 31 pages of my own notes on NLP, notes I had carefully created during an AI engineering course. However, I found that I understood very little of it.

It felt odd and disheartening to have written something down yet not grasp it. I initially thought the issue was with me. But that wasn't the case. The real issue was that simply reading notes does not equate to true learning. My notes were packed with information intended for a version of me that already had some understanding, and you can't develop comprehension just by rereading a summary. So, I decided to change my approach. Instead of reading, I had the concepts explained to me one question at a time, starting from the basics, using only simple examples. No technical terms were permitted until I had proven I could understand them.

By the end of the day, I had reconstructed the four main concepts of practical NLP from the ground up, and I used them to create a functioning app that answers questions based on my own notes. Here's the complete journey, with the same examples that finally helped me understand, along with the code for each step so you can follow along.

Start with the dumbest possible question

Imagine you want a computer to sort emails into "spam" and "not spam." Here's the catch: the computer has never read a word in its life. The only thing it can do, the only thing it has ever been able to do, is math on numbers.

So before it can sort a single email, one problem comes first: the words have to become numbers. That sentence turned out to be the foundation of everything. All of this branch of NLP is just one job: turn text into numbers without losing the meaning that matters.

My first instinct was to turn each letter into a number. It's a reasonable guess, and it's actually how computers store text underneath. But it captures spelling, not meaning. "win" and "bin" look almost identical as numbers, yet mean totally different things. The meaning of an email lives in its words, not its letters.

Bag of Words: count, don't spell

So we work with whole words. Take three emails:

"win money now"
"money money money"
"see you tomorrow"

List every distinct word (that's the vocabulary), give each a column, and for each email count how many times each word appears. "win money now" becomes 1, 1, 1, 0, 0, 0. "money money money" becomes 0, 3, 0, 0, 0, 0. Suddenly every email is a row of pure numbers, and a computer can compare them.

scikit-learn does exactly this in three lines:

from sklearn.feature_extraction.text import CountVectorizer

emails = ["win money now", "money money money", "see you tomorrow"]

vectorizer = CountVectorizer()
X = vectorizer.fit_transform(emails)

print(vectorizer.get_feature_names_out())  # the vocabulary (the columns)
print(X.toarray())                         # each row = one email as word-counts

That's it. That's the intimidating-sounding "Bag of Words." I had read about it and bounced off it; here I did it by hand in two minutes, then in three lines of code.

It's called a bag for a reason, and the reason is also its flaw. Imagine tossing a sentence's words into a paper bag and shaking it. You still know which words are inside and how many, but the order is gone. "win money now" and "now win money" produce the identical row. Usually harmless. But consider "dog bites man" versus "man bites dog": same three words, one is a boring Tuesday and the other is front-page news. To Bag of Words they're identical. That weakness is exactly why fancier methods had to be invented later.

TF-IDF: not all words deserve equal weight

Bag of Words has a second problem: it treats every word as equally important. The word "the" is in nearly every email, so knowing an email contains "the" tells you nothing. Meanwhile a rare word like "viagra" is a screaming signal. Yet Bag of Words counts them the same.

TF-IDF fixes this with two dials multiplied together:

TF (term frequency): how often a word appears in this one email. If a message says "money money money money," it's clearly about money. Repetition means importance.
IDF (inverse document frequency): how rare the word is across the whole pile, measured by how many separate emails contain it. Common word → tiny score. Rare word → big score. ("Inverse" just means flipped: more documents, smaller score.)

Multiply them, and something beautiful happens. Take "the": it appears a lot (high TF) but it's everywhere (near-zero IDF), so high × almost-zero ≈ zero. The word silences itself. Nobody handed the computer a list of words to ignore. The math removed the filler on its own. Meanwhile "viagra" in a spam email is repeated (high TF) and rare (high IDF), so it lights up bright.

Same API, one word swapped:

from sklearn.feature_extraction.text import TfidfVectorizer

vectorizer = TfidfVectorizer()
X = vectorizer.fit_transform(emails)

print(X.toarray().round(2))  # same shape, but now weighted by rarity

I tested the idea on "win win win money the the" and correctly predicted "win" would score highest, repeated and rare, while "the" collapsed to nothing. The method had taught me to think the way it thinks.

Embeddings: giving words a place on a map

Both methods above share a blindness: to them, "money" and "cash" are as unrelated as "money" and "banana." Each word is just its own separate column, with nothing connecting them. They have no concept that two different words can mean nearly the same thing.

Embeddings fix this with one gorgeous idea: put every word on a map of meaning. Picture a giant map where each word is a dot. We place words that mean similar things near each other, and unrelated words far apart. "cash" sits right next to "money"; "banana" is way over by "apple." A word's coordinates on that map, written as numbers, are its embedding. "king" lands closer to "queen" than to "bicycle," because the map is organized by meaning.

But how does a computer that can't read decide where to put each word? Through the company a word keeps. It reads millions of sentences and notices that "money" and "cash" are both surrounded by the same neighbors: borrow, pay, bank, withdraw. Same company, same neighborhood. "banana" keeps different company (eat, peel, ripe, fruit), so it lands far away. The computer never knows what any word means; it just matches patterns of context. (The real map isn't flat with two directions; it has hundreds, which is why an embedding is a long list of numbers. The idea is identical: close = similar, far = different.)

A pre-trained model hands you those coordinates directly:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
vecs = model.encode(["money", "cash", "banana"])

print(vecs.shape)  # (3, 384) → three words, each a dot with 384 coordinates

The kicker: it's not only single words. A whole sentence, or a whole note, can become a dot too, and that's the hinge the entire next step swings on.

RAG: I accidentally invented it

Here's where it all paid off. Imagine every note in my wiki is a dot on the meaning map. Then I type a question, and that question becomes a dot on the same map. To find the note that answers it, I just grab the nearest dots.

That's the entire idea behind RAG (Retrieval-Augmented Generation):

Turn the question into a dot (embed it).
Find the nearest note-dots on the map (retrieval).
Hand those notes to a language model and say "answer using only these."
The model writes an answer grounded in my actual notes instead of guessing.

Most people learn RAG by copying a tutorial and have no idea what's happening underneath. I arrived at it by reasoning, which meant I understood every layer before I wrote a line of code.

Synapse: making it real

So I built it, in a Jupyter notebook, and named it Synapse, because a synapse is the connection between two neurons, which is exactly what embeddings do: connect related notes by meaning.

The pipeline is just the four ideas above, in order.

1. Load every note:

from pathlib import Path

WIKI = Path("path/to/my/wiki")
notes = [{"path": str(f), "text": f.read_text(encoding="utf-8")}
         for f in WIKI.rglob("*.md")]

print(f"Loaded {len(notes)} notes")

2. Embed each note into a dot on the map:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode([n["text"] for n in notes])  # shape (N, 384)

3. Retrieve the nearest notes to a question:

from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

question = "what is the difference between stemming and lemmatization?"
q_emb = model.encode([question])

scores = cosine_similarity(q_emb, embeddings)[0]  # "near = similar", as a number
top = np.argsort(scores)[::-1][:3]                # the 3 closest notes

4. Generate a grounded answer from those notes:

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from your environment

context = "\n\n---\n\n".join(notes[i]["text"] for i in top)
prompt = f"""Answer the question using ONLY the notes below.
If the answer isn't in the notes, say you don't know.

NOTES:
{context}

QUESTION: {question}"""

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=500,
    messages=[{"role": "user", "content": prompt}],
)
print(resp.content[0].text)

That last instruction ("if the answer isn't in the notes, say you don't know") is the anti-hallucination guard. It's the difference between a toy and something you can trust.

I asked it: "What's the difference between stemming and lemmatization?" It pulled up exactly the right notes and wrote an answer that reproduced my own comparison table: the tools, the "studies → studi" example, all of it. Not from the model's training. From my brain, retrieved and read back to me.

What actually made it click

An hour into all this, I'd gone from "I understand nothing" to deriving RAG on my own. The lesson wasn't really about NLP. It was about how to learn:

Reading is not understanding. I'd mistaken having notes for having knowledge. The fix was active discovery: being asked a question and having to reach for the answer, one small step at a time, every abstract idea anchored to something concrete (a paper bag, a map, a spam email). And then building, because nothing reveals what you don't understand faster than making it run.

If you're staring at material that won't stick, try this: stop reading it. Have it asked of you instead. Start from the dumbest possible question and refuse to move on until each piece genuinely makes sense. You can get further in a day than you'd believe.

Next up for Synapse: chunking notes for sharper retrieval, citing its sources, a real frontend, and a local-model version. The journey continues. I'll write that one up too.

DEV Community: Sabi Mantock

Learning LangChain

Start small: messages and templates

The pipe

Now RAG, with the same pieces

What this changed for me

Going Back to TypeScript Basics

TypeScript started making more sense when I stopped fighting it

Generics weren't as scary as they looked

I managed to confuse Pick and Omit

Then things started connecting

Type predicates were another good example

API data made unknown click for me

By the end, the types were doing something useful

So, do I know TypeScript now?

The Joy of Learning the Basics Again

Starting from the beginning again

Functions exposed a few gaps

Arrays were where things started getting more interesting

I had been using callbacks without really thinking about them

Destructuring finally stopped feeling like magic

Spread and rest made more sense this time

Async JavaScript was probably the most important part

async/await made everything easier to reason about

Fetch tied everything together

Modules were a good place to finish

The main thing I realised

From "I Understood Nothing" to Building a RAG App

Start with the dumbest possible question

Bag of Words: count, don't spell

TF-IDF: not all words deserve equal weight

Embeddings: giving words a place on a map

RAG: I accidentally invented it

Synapse: making it real

What actually made it click

API data made `unknown` click for me

`async/await` made everything easier to reason about