DEV Community: Taha hussein

How I Built TokenSaver: An Image Optimizer for AI Tools

Taha hussein — Wed, 07 Oct 2026 22:12:44 +0000

I recently built a small Firefox extension called TokenSaver.

The idea started with a simple observation:

AI tools don't necessarily need every pixel in a huge screenshot.

But we often send them exactly that.

A screenshot from a MacBook can easily be thousands of pixels wide. If I'm asking an AI model to read a small piece of code or understand an error message, most of that image may not be useful.

So I built a tool to optimize the image before sending it.

👉 Try TokenSaver on Firefox

The problem

AI coding assistants are becoming part of my daily development workflow.

I regularly send screenshots for things like:

UI debugging
Error messages
Code snippets
Documentation
Terminal output
Design feedback

The problem is that screenshots can be much larger than necessary.

A 3000×2000 screenshot and a smaller optimized version may contain essentially the same information for the task I'm asking the model to perform.

But the image still has to be processed as an image input.

That's where the idea for TokenSaver came from.

The idea

The workflow is intentionally simple:

Screenshot
    ↓
TokenSaver
    ↓
Optimize dimensions
    ↓
Estimate image tokens
    ↓
AI tool

Instead of:

Screenshot
    ↓
AI tool

The goal isn't to destroy image quality.

It's to remove unnecessary image data while keeping the information that matters.

What TokenSaver does

TokenSaver currently supports several ways of providing an image:

File picker
Drag and drop
Paste screenshots directly

It can then optimize the image based on the selected mode.

The extension also displays an estimated token count before and after optimization.

This gives you an idea of whether the optimization actually made a meaningful difference.

Different optimization modes

I didn't want to create a single "compress" button.

Sometimes quality matters.

Sometimes saving as much as possible matters more.

So TokenSaver provides different optimization modes, including:

Sharp — prioritize image quality
Auto — balance quality and optimization
Max Saving — prioritize reducing the image size

This makes it possible to choose based on the type of screenshot.

For example, I would treat a screenshot containing tiny code text differently from a simple UI screenshot.

Why local processing?

This was an important design decision.

A screenshot can contain sensitive information.

As developers, we regularly have screenshots containing:

API responses
Source code
Customer information
Internal dashboards
Terminal output
Personal data

I didn't want users to upload those images to another service just to resize them.

So TokenSaver performs the image optimization locally in the browser.

No TokenSaver server is required to process the image.

One interesting lesson

The biggest lesson from building this wasn't image resizing.

It was realizing that image optimization for AI is different from normal image optimization.

Traditional image compression usually focuses on:

File size
JPEG/WebP quality
Bandwidth
Storage

For AI inputs, another question becomes important:

How much visual information does the model actually need for this task?

That's a different optimization problem.

What I'm working on next

TokenSaver is currently available for Firefox.

I'm keeping the project small for now and using real user feedback to decide what should come next.

Possible directions include broader browser support and additional AI-input optimizations.

But I don't want to add features just because they sound interesting.

I'd rather solve one problem properly first.

Try it

If you use AI tools for development and regularly paste screenshots, give it a try:

👉 Install TokenSaver – Image Optimizer

It's free, and I'd genuinely like to hear what happens with your own screenshots.

Especially the difficult cases where the image contains small text or code.

About the developer

I'm Taha Hussein, an engineer working with iOS development and AI.

LinkedIn: https://www.linkedin.com/in/taha-hussein-b0a583425/

YouTube: https://www.youtube.com/@Tahahussein-Ai

Build a Tiny Semantic Search Engine in Python

Taha hussein — Mon, 21 Sep 2026 08:58:12 +0000

What if a search engine could understand that these two sentences are related?

"I love programming"

"I enjoy coding"

They don't use the exact same words, but their meanings are close.

That's the basic idea behind semantic search.

In this tutorial, we'll build a tiny semantic search engine in Python using:

Sentence Transformers
Embeddings
Cosine Similarity
scikit-learn

No database.
No RAG.
No complicated architecture.

Just the core idea.

Step 1 — Install the Libraries

pip install sentence-transformers scikit-learn

Then import them:

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

Step 2 — Load an Embedding Model

model = SentenceTransformer("all-MiniLM-L6-v2")

This model converts text into numerical embeddings.

Think of the process as:

"I love programming"
        ↓
   Embedding Model
        ↓
   [0.02, -0.14, 0.08, ...]

The sentence has now been represented by numbers.

Step 3 — Create Some Sentences

sentences = [
    "I love programming",
    "I enjoy coding",
    "The weather is very hot"
]

Generate their embeddings:

embeddings = model.encode(sentences)

print(embeddings.shape)

You'll get something similar to:

(3, 384)

So we have:

3 sentences
384 numbers for each sentence

Step 4 — Compare the Sentences

Now let's calculate their similarity:

similarity = cosine_similarity(embeddings)

print(similarity)

You might see:

[
 [1.00, 0.63, 0.12],
 [0.63, 1.00, 0.22],
 [0.12, 0.22, 1.00]
]

Remember our sentences:

0 → I love programming
1 → I enjoy coding
2 → The weather is very hot

So:

similarity[0][1]

means:

"I love programming"
        ↕
"I enjoy coding"

and gives approximately:

0.63

That's considerably higher than the similarity between programming and weather.

Step 5 — Let's Build an Actual Search

Now we'll create a few documents:

documents = [
    "Python is a programming language.",
    "Machine learning is a branch of artificial intelligence.",
    "The weather is very hot today.",
    "Football is a popular sport."
]

Our user will search for:

query = "I want to learn coding"

The interesting question is:

Which document is closest to this query?

Step 6 — Embed the Documents

document_embeddings = model.encode(documents)

Each document now has its own embedding.

Step 7 — Embed the Query

query_embedding = model.encode([query])

Now we have:

Query → Embedding

Documents → Embeddings

Step 8 — Calculate Similarity

scores = cosine_similarity(
    query_embedding,
    document_embeddings
)[0]

print(scores)

You might get:

[0.70, 0.55, 0.12, 0.08]

The exact numbers can vary.

But the interpretation is:

Python                    0.70
Machine learning          0.55
Weather                   0.12
Football                  0.08

The Python document is the closest match to our query.

Step 9 — Rank the Search Results

Let's make the output easier to read:

results = sorted(
    zip(scores, documents),
    reverse=True
)

for score, document in results:
    print(f"{score:.3f} - {document}")

Example:

0.700 - Python is a programming language.
0.550 - Machine learning is a branch of artificial intelligence.
0.120 - The weather is very hot today.
0.080 - Football is a popular sport.

Congratulations.

You just built a tiny semantic search engine.

The Complete Code

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

model = SentenceTransformer("all-MiniLM-L6-v2")

documents = [
    "Python is a programming language.",
    "Machine learning is a branch of artificial intelligence.",
    "The weather is very hot today.",
    "Football is a popular sport."
]

query = "I want to learn coding"

document_embeddings = model.encode(documents)
query_embedding = model.encode([query])

scores = cosine_similarity(
    query_embedding,
    document_embeddings
)[0]

results = sorted(
    zip(scores, documents),
    reverse=True
)

for score, document in results:
    print(f"{score:.3f} - {document}")

What Did We Actually Build?

The architecture is surprisingly simple:

              Query
                ↓
           Embedding
                ↓
       ┌────────┴────────┐
       ↓        ↓        ↓
    Document Document Document
    Embedding Embedding Embedding
       └────────┬────────┘
                ↓
       Cosine Similarity
                ↓
          Similarity Scores
                ↓
             Ranking
                ↓
        Search Results

Why Not Just Search for Keywords?

Suppose the user searches:

"I want to learn coding"

But the document says:

"Python is a programming language."

There may be no exact match for the word coding.

Semantic search doesn't depend only on exact words.

The embedding model creates representations that allow us to compare the meaning of the texts.

That's why:

coding

and:

programming

can produce relatively similar embeddings.

Three Concepts to Remember

If you're learning NLP or modern AI systems, keep these three concepts separate.

1. Embedding

Turns text into numbers.

Text → Numbers

2. Cosine Similarity

Compares two embeddings.

Embedding A
     +
Embedding B
     ↓
Similarity Score

3. Semantic Search

Uses those similarities to find relevant information.

Query
 ↓
Embedding
 ↓
Compare
 ↓
Rank
 ↓
Results

Where Do We Go From Here?

This example is intentionally small.

Real applications may contain thousands or millions of documents, so calculating similarity against every document isn't always efficient.

That's where techniques such as vector databases and approximate nearest-neighbor search become useful.

And when retrieved documents are passed to a language model to help answer a user's question, we enter the world of Retrieval-Augmented Generation (RAG).

But before moving there, make sure this basic pipeline is clear:

Text
 ↓
Embedding
 ↓
Similarity
 ↓
Search

Once this clicks, the more advanced systems become much easier to understand.

LinkedIn: https://www.linkedin.com/in/taha-hussein-b0a583425/

YouTube: https://www.youtube.com/@Tahahussein-Ai

RAG Explained: How to Build AI Systems That Can Use Your Own Knowledge

Taha hussein — Fri, 18 Sep 2026 09:07:44 +0000

Large Language Models are powerful.

Your application may need information that was never included in the model's training data.

Maybe you want an AI assistant that understands:

Your company's documentation
Internal PDFs
Product information
Customer support articles
Legal documents
Technical documentation
A private knowledge base

Should you fine-tune the entire model?

Usually, that's not the first thing I would try.

A more natural architecture is:

Retrieval-Augmented Generation

or simply:

RAG

1. What Is RAG?

The basic idea is simple.

Instead of asking the LLM to answer from its internal knowledge alone:

User
 ↓
LLM
 ↓
Answer

we first retrieve relevant information:

User Question
      ↓
Retrieve relevant knowledge
      ↓
Context
      ↓
LLM
      ↓
Answer

The model receives the relevant information as part of its context.

2. A Simple Example

Imagine you have a company policy document.

It contains:

Employees can request annual leave
after completing three months of employment.

A user asks:

Can I request annual leave during my first month?

A generic LLM may not know your company's actual policy.

Instead, a RAG system searches your company's knowledge base.

It finds:

Employees can request annual leave
after completing three months of employment.

Then the application sends something like:

Context:
Employees can request annual leave
after completing three months of employment.

Question:
Can I request annual leave during my first month?

to the model.

Now the model has the relevant information.

3. The RAG Pipeline

A typical RAG system looks like:

Documents
    │
    ▼
Document Loading
    │
    ▼
Chunking
    │
    ▼
Embeddings
    │
    ▼
Vector Database
    │
    │
    │
User Question
    │
    ▼
Question Embedding
    │
    ▼
Similarity Search
    │
    ▼
Relevant Chunks
    │
    ▼
LLM
    │
    ▼
Answer

Let's break this down.

4. Step 1 — Collect Documents

Your knowledge source might contain:

PDF
Markdown
HTML
Database records
Documentation
TXT
CSV

For example:

company_docs/
├── policies.pdf
├── onboarding.md
├── security.md
└── benefits.pdf

5. Step 2 — Chunk the Documents

You usually don't want to send an entire 200-page PDF to the model for every question.

Instead, split the document into smaller pieces.

For example:

Document
   ↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...
Chunk 100

The chunk size matters.

If chunks are too small:

Context may lose meaning.

If chunks are too large:

Retrieval may become less precise
and context becomes more expensive.

Chunking is therefore an engineering decision, not just a preprocessing step.

6. Step 3 — Convert Text Into Embeddings

Now we need a way to represent semantic meaning numerically.

An embedding model converts text into vectors.

For example:

"How do I reset my password?"

might become:

[0.21, -0.13, 0.82, ...]

Another sentence:

"I forgot my account password."

may produce a vector that is close to the first one.

The important idea is:

Similar meanings should produce relatively similar vector representations.

7. Step 4 — Store the Vectors

We can store the embeddings in a vector database or another retrieval system.

Conceptually:

Chunk                    Vector
-----------------------------------------
Password reset      →   [0.21, 0.11, ...]
Refund policy       →   [0.82, 0.42, ...]
Vacation policy     →   [0.17, 0.93, ...]

When the user asks a question, we embed the question too.

Then we search for vectors that are close to the query vector.

8. Step 5 — Retrieve Relevant Information

Suppose the user asks:

How can I reset my password?

The retriever might return:

1. Password Reset Guide
2. Account Security Policy
3. Login Troubleshooting

Those documents become context for the LLM.

9. Step 6 — Generate the Answer

Finally:

Question
+
Retrieved Context
        ↓
      LLM
        ↓
     Answer

The model can now generate an answer grounded in the retrieved information.

A good production system may also instruct the model:

Answer only using the provided context.

If the answer is not contained in the context,
say that the information was not found.

This can help reduce unsupported answers, although RAG does not automatically eliminate hallucinations.

10. RAG Does Not "Teach" the Model

This is one of the most important concepts.

When you add a PDF to a RAG system, you are generally not changing the model's weights.

Instead:

Model
  +
Retrieved Context
  =
Context-aware response

Compare that with fine-tuning:

Dataset
   ↓
Training
   ↓
Updated Parameters

This distinction is fundamental.

11. RAG vs Fine-Tuning

A simple comparison:

Problem	Common approach
Give the model private documents	RAG
Information changes frequently	RAG
Company documentation	RAG
Improve a specific output format	Fine-tuning
Teach a specialized behavior	Fine-tuning
Need both knowledge + behavior	RAG + Fine-tuning

These aren't strict rules.

The correct architecture depends on the application, data, latency, cost, and evaluation results.

12. The Real Difficulty: Retrieval

A beginner might think:

RAG = Vector Database + LLM

But production RAG is more complicated.

What if the retriever returns the wrong documents?

Then even a powerful LLM receives bad context.

You get:

Bad retrieval
     ↓
Bad context
     ↓
Bad answer

So improving RAG often means improving retrieval.

13. Retrieval Quality Matters

Suppose the knowledge base contains:

Refund Policy
Password Policy
Shipping Policy
Account Deletion Policy

User:

How long does a refund take?

A good retriever should prioritize:

Refund Policy

If it retrieves:

Password Policy

the LLM cannot magically recover the missing information.

This is why RAG systems need evaluation.

14. Beyond Basic Vector Search

A more advanced architecture might look like:

User Question
      ↓
Query Processing
      ↓
Hybrid Retrieval
      ↓
Vector Search
      +
Keyword Search
      ↓
Reranking
      ↓
Top Documents
      ↓
LLM

Depending on the application, you may use:

Metadata filtering
Hybrid search
Rerankers
Query rewriting
Multiple retrieval strategies
Citation generation
Retrieval evaluation

The more serious the application, the more important these components become.

15. RAG Is an AI Engineering Problem

This is why I think RAG is such an important project for anyone learning AI engineering.

It combines multiple areas:

Python
   +
NLP
   +
Embeddings
   +
Vector Search
   +
LLMs
   +
Prompt Engineering
   +
Backend Engineering
   +
Evaluation

You are no longer simply calling an AI API.

You are designing a system around a model.

16. A Project I Would Build

If I were learning RAG from scratch, I would build:

"Personal AI Knowledge Assistant"

Input:

PDFs
Markdown
Notes
Documentation

Architecture:

              Documents
                  │
                  ▼
               Chunker
                  │
                  ▼
             Embedding Model
                  │
                  ▼
            Vector Database
                  │
                  │
User ───────► Retriever
                  │
                  ▼
             Relevant Context
                  │
                  ▼
                 LLM
                  │
                  ▼
               Answer

Then add:

Sources
Conversation history
Metadata filtering
Evaluation
Streaming
Authentication

Now you have a real AI engineering portfolio project.

17. What I Would Learn After RAG

Once you understand the architecture, continue with:

RAG
 ↓
Advanced Retrieval
 ↓
Tool Calling
 ↓
Structured Outputs
 ↓
Agents
 ↓
Agent Workflows
 ↓
Evaluation
 ↓
LLMOps

At that point, you're moving from:

"I can call an LLM API"

to:

"I can design AI-powered systems."

That distinction is extremely important.

Final Thoughts

RAG is not a magic solution.

It is an architecture that gives an LLM access to relevant external information at inference time.

The core idea is simple:

Retrieve
   ↓
Augment
   ↓
Generate

But building a reliable RAG application requires much more than connecting a vector database to an LLM.

You need to think about:

Data quality
Chunking
Embeddings
Retrieval
Ranking
Context
Prompting
Evaluation
Latency
Cost

And that's exactly what makes RAG such a valuable project for an aspiring AI Engineer.

Connect With Me

YouTube: https://www.youtube.com/@Tahahussein-Ai

GitHub: https://github.com/Taha2hussein

LinkedIn: https://www.linkedin.com/in/taha-hussein-b0a583425/

I share practical content about Python, Machine Learning, Deep Learning, LLMs, RAG, and AI Engineering.

I Built a Mini-GPT From Scratch to Actually Understand Transformers (Not Just Copy Code)

Taha hussein — Tue, 15 Sep 2026 09:29:25 +0000

**# Full Post Content (Markdown, ready to paste into DEV.to editor)

A few weeks ago, I asked an AI assistant to build me a poetry-generation model using a Transformer architecture. It worked. The output was decent. But when I read through the code, I could only really explain about 80% of it.

That bothered me more than it should have.

So I went back to the fundamentals: Attention, Query/Key/Value, Multi-Head Attention, positional encoding — and rebuilt everything from scratch, line by line, without copying from the original code. No shortcuts this time.

The result is a small, fully working GPT-style model, and a step-by-step video series (in Arabic, with English code) documenting the entire build.

What the series actually covers

Instead of jumping straight to a wall of code, I broke the build into small, focused pieces:

Embeddings: turning word IDs into vectors, and why we need a separate positional embedding on top of the token embedding
Self-Attention: building Head from scratch — the Q/K/V projections, the scaled dot-product, causal masking, softmax, and the final weighted sum
Multi-Head Attention: running several attention heads in parallel and merging them with a projection layer
Feed-Forward + Residual Connections: why attention alone isn't enough, and why skip connections matter for training stability
The full MiniGPT class: stacking everything into blocks, adding the final LayerNorm and lm_head
Training loop: computing cross-entropy loss, running backprop, and actually watching the loss go down on a tiny toy dataset

Here's a snippet from the core attention head, one of the most important 15 lines in the whole project:

class Head(nn.Module):
    def __init__(self, head_size):
        super().__init__()
        self.key = nn.Linear(n_embd, head_size, bias=False)
        self.query = nn.Linear(n_embd, head_size, bias=False)
        self.value = nn.Linear(n_embd, head_size, bias=False)
        self.register_buffer("tril", torch.tril(
            torch.ones(block_size, block_size)))

    def forward(self, x):
        B, T, C = x.shape
        k = self.key(x)
        q = self.query(x)
        v = self.value(x)
        wei = q @ k.transpose(-2, -1) * C**-0.5
        wei = wei.masked_fill(
            self.tril[:T, :T] == 0, float("-inf"))
        wei = F.softmax(wei, dim=-1)
        return wei @ v

Nothing fancy — no external attention libraries, no shortcuts. Just nn.Linear, matrix multiplication, and a triangular mask to prevent the model from "cheating" by looking at future tokens.

Why rebuild something that already works?

Because there's a real difference between:

"I can read this code and follow the logic"
"I can write this from an empty file and explain every decision"

The first gets you through a tutorial. The second is what actually sticks when you're debugging a production model six months later, or when someone in an interview asks you to explain why attention scores are scaled by 1/sqrt(head_size).

The video series

The full series (18 short episodes, 3–7 minutes each) walks through this build in Arabic, but all the code, variable names, and comments are in English — so it should be followable even if you don't speak Arabic.

📺 https://www.youtube.com/@Tahahussein-Ai

What's next

Now that the Transformer fundamentals are solid, I'm moving on to tokenization (BPE) and then into fine-tuning real pretrained models (LoRA/QLoRA) — building on this same "understand it deeply, then apply it" approach.

If you've ever felt like you understand a model "well enough" but couldn't quite rebuild it yourself, I'd genuinely recommend trying this exercise. It's humbling, but it's the fastest way I've found to close that gap.

Suggested tags: #machinelearning #python #ai #tutorial #showdev

PyTorch Tutorial for Beginners: Learn Deep Learning with Python

Taha hussein — Tue, 15 Sep 2026 09:22:38 +0000

PyTorch for Beginners: What You Actually Need to Understand

If you're learning Deep Learning, you'll probably encounter PyTorch very early.

But there's a common mistake:

People learn PyTorch syntax without understanding what PyTorch is actually doing.

Let's fix that.

What is PyTorch?

PyTorch is a machine learning framework used to create and train neural networks.

It provides several important components:

Tensors
Automatic differentiation
Neural network modules
Optimizers
GPU acceleration
Data loading utilities

The important thing is understanding how these components work together.

Start With Tensors

import torch

x = torch.tensor([1, 2, 3])

print(x)

Tensors are the basic data structure used throughout PyTorch.

Neural networks perform mathematical operations on tensors.

Then Understand Gradients

Training a neural network requires gradients.

PyTorch can calculate them automatically:

x = torch.tensor(2.0, requires_grad=True)

y = x ** 2

y.backward()

print(x.grad)

The result is:

because the derivative of x² is 2x.

Then Build a Model

import torch.nn as nn

model = nn.Sequential(
    nn.Linear(10, 32),
    nn.ReLU(),
    nn.Linear(32, 1)
)

This creates a simple neural network.

But creating the model is only one part of Deep Learning.

The Most Important Part: Training

A typical training step looks like:

optimizer.zero_grad()

prediction = model(x)

loss = criterion(prediction, y)

loss.backward()

optimizer.step()

If you understand these five lines, you're already understanding one of the fundamental patterns of Deep Learning.

Why Does This Matter?

Because the same general idea appears in much more advanced models.

The architecture changes.

The data changes.

The loss function changes.

But the fundamental training process remains surprisingly similar.

This is why I recommend learning PyTorch from the fundamentals instead of jumping directly into huge pre-trained models.

From PyTorch to Transformers

Once you're comfortable with:

Tensors
Gradients
Neural Networks
Loss functions
Optimizers
Training loops

you can start learning:

Attention → Self-Attention → Multi-Head Attention → Transformers → LLMs

That's where PyTorch becomes particularly powerful.

What's Your Experience With PyTorch?

Are you learning PyTorch for:

A) Computer Vision
B) NLP
C) Transformers / LLMs
D) General Deep Learning
E) Research

I'd love to know what you're currently building.

I also publish practical tutorials about PyTorch, Transformers, Machine Learning frameworks, and modern AI.

YouTube: https://www.youtube.com/@Tahahussein-Ai

GitHub: https://github.com/Taha2hussein