DEV Community: Mbonimpa Kelia

# What I Learned About Computer Vision as a Beginner: My kLab TekHer AI Journey

Mbonimpa Kelia — Tue, 13 Oct 2026 14:03:25 +0000

A beginner's reflection on the kLab TekHer AI Program — Cohort 2

When I started the "Introduction to Computer Vision" notebook, I thought I was going to learn how to make computers "see." I was half right. What I actually learned is that computers don't see anything at all — they just do math on grids of numbers. And once that clicked, everything else made sense.

Here's what I learned, the challenges I ran into, and how I got past them.

What I Learned

An image is just numbers — lots of them The first lesson was the most surprising. A photo isn't a picture to a computer. It's a giant grid of numbers.

My photo of the bus was 1080 rows × 810 columns × 3 channels (R, G, B) = 2,624,400 numbers. That's it. No "bus," no "people," no "sunlight" — just over 2.6 million numbers between 0 and 255.

Each pixel has three values:

Red, Green, Blue (in that order)

0 = none of that color, 255 = full of that color

White = (255, 255, 255). Black = (0, 0, 0).

That was my first "aha" moment. When I removed the red channel from an image, all the white areas turned cyan. Why? Because white − red = green + blue = cyan. Simple arithmetic, but it changed how I think about photos.

Filters: how a computer finds edges Next, I learned about filters (also called kernels). A filter is a tiny grid of numbers — usually 3×3 or 5×5 — that slides across the image. At each position, it multiplies the neighboring pixels by the filter's weights and adds the results. That becomes the new value of the center pixel.

Two classic filters I built by hand:

Filter What it does
Box blur (all weights = 1/25) Averages each pixel with its 25 neighbors → softens the image
Sobel x ([-1,0,1], [-2,0,2], [-1,0,1]) Subtracts left side from right side → finds vertical edges
Sobel y (Sobel x transposed) Finds horizontal edges
When I ran Sobel x on the bus photo, I could see exactly where the vertical edges were — the sides of the bus, the traffic sign, the people's arms. But the horizontal edges (like the roof of the bus) were invisible until I ran Sobel y. Combining both with sqrt(x² + y²) gave me every edge.

This is what a CNN does. The difference is that a CNN doesn't use hand-picked weights — it learns them from thousands of labeled photos.

Classification: one label for a whole image I loaded a pretrained YOLO classifier (trained on ImageNet — 1.2 million photos, 1,000 classes) and ran it on the bus photo. It said:

minibus — 57.1%

police_van — 33.7%

trolleybus — 4.2%

...

Top guess was correct! But the notebook asked me to test it on something I know well: a Rwandan agaseke (traditional woven basket).

The result? "vase" at 74.4%.

The model had never seen an agaseke. It looked at the shape, decided it most resembled a vase, and gave me a confident but wrong answer.

This was the single most important lesson in the whole notebook.

Object Detection: what and where I moved on to object detection — a YOLO model (yolo11n.pt) trained on COCO (80 everyday Western classes: person, car, bus, dog, chair, laptop...).

On the bus photo, it worked beautifully:

bus — 94%

person — 89%, 88%, 86%, 62%

5 boxes, correctly drawn around each object.

On my agaseke, it drew 2 boxes:

vase — 45% (covering the whole basket)

bird — 58% (around the pointed tip of the lid)

Both wrong. But the boxes themselves were reasonably placed. The model could see where the object was — it just couldn't name it.

Segmentation: pixel-by-pixel Segmentation is the most detailed level. Instead of a rectangle, the model predicts a mask — a grid of 0s and 1s where 1 means "this pixel belongs to the object."

On the bus photo, the segmenter produced clean outlines of the bus and each person. On my agaseke, the mask traced the shape of the basket beautifully — but again, the label was "vase."

Key insight: the AI could see the shape perfectly. It just had never learned the word "agaseke."

When models fail The last section was the most eye-opening. I took the same photo and made it harder in 5 ways:

Variant Result
Original 5 objects, 4 people — perfect
Very dark 6 objects (with a false "skateboard")
Upside down 1 object, mislabeled as "screen"
Low resolution 0 objects — total failure
Blurry A few objects, some misses
The upside-down image crushed the model. Why? Because the model's internal filters were trained on photos where "up" is sky and "down" is ground. Flip it and everything breaks.

The low-resolution image also crushed it. Fine details = the entire basis of detection.

Lesson: AI is not magic. It's pattern matching. If the pattern is unfamiliar, it fails.

The Challenges I Faced
Challenge 1: "NameError: name 'np' is not defined"
What happened: I ran a cell that used np (NumPy) and Image (PIL), but the notebook didn't know what those were. The cell crashed.

Why: Google Colab doesn't remember variables between sessions. When I restarted the runtime (or closed and reopened the notebook), all the import statements were forgotten. The setup cell had to be re-run.

How I fixed it: I learned the golden rule — always run cells from the top down, in order, one at a time. If you see any NameError, scroll up and look for the cell that defines the missing name.

Challenge 2: "NameError: name 'convolve' is not defined"
What happened: I added a new cell to test new kernels (sharpen, big blur, Sobel y), but the convolve function — defined in the previous cell — wasn't in memory anymore.

Why: Same issue as Challenge 1. I had skipped running the earlier cell.

How I fixed it: Re-ran the cell that starts with def convolve(gray, kernel):. Immediately, my new test cell worked.

Challenge 3: Colab couldn't find my image
What happened: I wrote IMAGE_PATH = r"C:\Users\PC\Documents\klab\computer science.jpg" and got a FileNotFoundError.

Why: Google Colab runs on a cloud server. It has no access to your C: drive. Your files are on your laptop; Colab is in Google's data center.

How I fixed it: I used the correct upload workflow:

python
from google.colab import files
uploaded = files.upload()
Then clicked "Choose Files," selected my image, and let Colab save it locally. I could then access it by filename (e.g., "Agaseke (1).jpg").

Bonus lesson: Colab sometimes renames your file — for example, Agaseke.jpg → Agaseke (1).jpg. To avoid hard-coding a wrong name, I used IMAGE_PATH = list(uploaded.keys())[0] to grab whatever filename Colab assigned.

Challenge 4: The upload widget disappeared
What happened: A message said: "Upload widget is only available when the cell has been executed in the current browser session."

Why: The runtime had disconnected in the background, so the "Choose Files" button became inactive.

How I fixed it: Re-ran the upload cell (Shift+Enter). The button came back. If it still didn't work, I could use IMAGE_PATH = "Agaseke (1).jpg" to load the file directly.

Challenge 5: Not sure whether to edit the existing cell or add a new one
What happened: I wasn't sure whether to change code inside an existing cell or add a new one.

How I fixed it: I asked, and the answer was:

If you're learning or experimenting → add a new cell. Safe, reversible.

If you're fixing a bug → edit the existing cell.

For the "Try it yourself" tasks → a new cell is usually cleanest.

Challenge 6: The domain gap — a lesson disguised as a bug
What happened: When I ran the classifier on my agaseke, it said "vase, 74.4%". I thought I had done something wrong.

Why: I hadn't. The model simply had never been trained on agaseke. It was doing exactly what it was supposed to — finding the closest thing it knew.

How I "fixed" it: I didn't. I learned from it. This is one of the most important unsolved problems in AI: a model trained on American photos will fail on Rwandan objects, even when it's technically "working."

What I Would Do Differently Next Time
Always run cells from the top before starting work.

Keep a "session check" cell at the top of my notebook that prints which image is loaded:

python
print("IMAGE_PATH =", IMAGE_PATH)
print("img shape =", img.shape)
Save intermediate copies of variables (like my_img = img.copy()) so I don't lose my original image when experimenting.

Predict before running. Every "Try it yourself" became more interesting when I stopped and thought about what would happen first.

Final Reflection
This notebook took me from "an image is a picture" to "an image is 2,624,400 numbers, filtered and classified by learned patterns." Along the way, I:

Manipulated RGB channels

Built blur and edge-detection filters

Ran a real ImageNet classifier

Ran a real COCO object detector

Ran a real segmentation model

Discovered the domain gap in person, using an agaseke.

The hardest part wasn't the code. It was realizing that the AI is doing exactly what I tell it to — I just have to give it training data that represents my world.

My biggest takeaway: If we want AI that works in Rwanda, we need to build it with Rwandan data. And that's the next thing I want to learn.

— Written after completing the "Introduction to Computer Vision" notebook, kLab TekHer AI Program, Cohort 2.

What I Learned About Word Embeddings While Building a FAQ Chatbot

Mbonimpa Kelia — Wed, 30 Sep 2026 13:26:50 +0000

When I set out to build a simple FAQ chatbot for Python programming questions, I thought I'd be done in a weekend. I was wrong — but in the best way. Along the way, I ran into a concept that changed how I think about text: word embeddings.

This post is a lessons-learned write-up of what I discovered. If you're a developer getting into NLP, this might save you a few hours of confusion.

What Are Word Embeddings, Anyway?
Computers don't understand words. They understand numbers. So any NLP system has to convert text into numbers before it can do anything useful.

The naive way to do this is one-hot encoding or bag-of-words: assign each word a number, and represent a sentence as a list of word counts. This works, but it has a big problem — it treats every word as completely independent. To a bag-of-words model, "car" and "automobile" are as unrelated as "car" and "banana."

Word embeddings solve this. An embedding represents each word as a dense vector of real numbers — usually 100 to 300 dimensions — where the position of the vector in space reflects the word's meaning. Words that appear in similar contexts end up close together in this vector space. "Dog" and "puppy" end up near each other. "King" and "queen" end up near each other. "Python" and "programming" end up near each other.

Why does this matter? Because once words are vectors, you can do math on them. You can measure similarity, find clusters, and even solve analogies.

The Method That Clicked for Me: Word2Vec
The assignment notes I was working from mentioned Word2Vec, and it's the one that finally made embeddings click.

Word2Vec comes in two flavors:

CBOW (Continuous Bag of Words): predicts a word from its surrounding context

Skip-gram: predicts the surrounding context from a word

The key insight is the distributional hypothesis: words that appear in similar contexts have similar meanings. If "cat" and "dog" both frequently appear near "pet," "feed," and "vet," Word2Vec learns that they're semantically related.

Training happens by sliding a window over a large corpus. For each word, the model tries to predict its neighbors. Over millions of examples, the weights of a small neural network adjust until each word has a useful vector. What surprised me is that nobody labels this data — the text itself is the supervision. You just throw a lot of text at it and it figures out meaning on its own.

The Analogy That Blew My Mind
The classic Word2Vec demo is this:

text
king - man + woman ≈ queen
Translated: take the vector for "king," subtract "man," add "woman" — and the closest vector to the result is "queen." The model wasn't told that kings and queens are related, or that man and woman are a gender pair. It learned both facts from raw text alone.

I tried to reproduce this with a Python example using gensim:

python
from gensim.models import Word2Vec

Assume `sentences` is a list of tokenized sentences

model = Word2Vec(sentences, vector_size=100, window=5, min_count=5)

Find words most similar to "python"

similar = model.wv.most_similar("python", topn=5)
print(similar)

[('programming', 0.71), ('java', 0.68), ('code', 0.65), ...]

The fact that a model trained on raw Wikipedia text knows "python" is close to "programming" still amazes me.

What I Struggled With
Here's the honest part: I did not use word embeddings in my final FAQ chatbot.

My project used TF-IDF, which is a sparse, frequency-based vectorization method — not an embedding. TF-IDF is fast, interpretable, and works great for small FAQ datasets. But it has a real limitation: it can't handle paraphrases.

For example, if a user asks "How do I set up Python?" and my FAQ has "How do I install Python?", TF-IDF sees "set up" and "install" as completely different words. It might miss the match. A word embedding model would recognise that "set up" and "install" mean the same thing and would match them correctly.

So I learned embeddings as theory but implemented TF-IDF in practice. If I were to expand this project to hundreds or thousands of FAQs, the very first upgrade I'd make is swapping TF-IDF for sentence embeddings like Sentence-BERT, which can encode entire questions into a single dense vector and handle paraphrasing gracefully.

Other Embedding Methods Worth Knowing
While learning, I also came across:

GloVe (Global Vectors): similar to Word2Vec but trained on global word co-occurrence statistics rather than a sliding window.

FastText: extends Word2Vec by treating words as bags of character n-grams. This means it can generate vectors for words it has never seen — very handy for typos or rare words.

Contextual embeddings (BERT, ELMo): the same word gets different vectors in different sentences. "Bank" in "river bank" vs. "money bank" gets two different vectors. This is the foundation of modern LLMs.

What I'd Tell Another Developer
If you're just starting with NLP:

Learn TF-IDF first. It's simpler, faster, and good enough for many tasks.

Learn Word2Vec next. It builds the intuition for why embeddings work.

Then try sentence embeddings (SBERT). This is the practical modern approach for semantic search.

Don't skip the theory. Understanding why embeddings work — the distributional hypothesis — makes it much easier to know when to use them.

Embeddings turned text into geometry. That's the mental shift that changed how I look at NLP problems.

Sources:

Mikolov et al., "Efficient Estimation of Word Representations in Vector Space" (2013)

Pennington et al., "GloVe: Global Vectors for Word Representation" (2014)

Bojanowski et al., "Enriching Word Vectors with Subword Information" (FastText, 2017)

Reimers & Gurevych, "Sentence-BERT" (2019)