Instead of starting with a large production-style application, I wanted to understand one of the fundamental parts of a RAG system:

How does a system decide which piece of a document is relevant to a user's question?

So I built a small personal learning project around something familiar: my resume.

The goal wasn't to build a production resume parser or commercial AI application. It was simply to learn by building and experimenting.

The project takes a resume from a .docx file, extracts the content, splits it into chunks, generates embeddings, and allows me to experiment with different retrieval approaches:

• Keyword search

• Semantic search

• Hybrid search

The basic pipeline

The overall flow looks like this:

Resume (.docx)
↓
Text extraction
↓
Chunking
↓
Embeddings
↓
Keyword / Semantic / Hybrid search
↓
Relevant chunks

The resume content is extracted from paragraphs and tables and split into overlapping chunks. In this experiment, I used roughly 500 words per chunk with around 100 words of overlap.

For semantic retrieval, I used:

BAAI/bge-small-en-v1.5

The embedding size is 384 dimensions.

For this learning project, the vectors are kept in memory rather than using a production vector database. The focus was understanding retrieval rather than building infrastructure.

Three ways to search

This was the most interesting part of the experiment.

Keyword, semantic, and hybrid search use different signals when deciding which chunk is relevant.

1. Keyword Search — Exact terms matter

Keyword search focuses on the actual words or tokens present in the query and document.

For example, if a resume contains:

Python, JavaScript, Azure, Docker

and the user searches for:

Python

an exact occurrence of Python is strong evidence that the chunk is relevant.

For a resume, keyword search can be useful for:

• Skills

• Technology names

• Company names

• Email addresses

• IDs

• Section titles

The simple keyword implementation in my project tokenizes the query and checks how many query tokens occur in each chunk.

Query terms → matching terms → ranked chunks

The trade-off is that keyword search doesn't naturally understand that different words can have the same meaning.

For example:

"current company"

and

"current organization"

may be conceptually related, but exact keyword matching doesn't automatically understand that relationship.

2. Semantic Search— Meaning matters

Semantic search takes a different approach.

Instead of asking only:

"Does this exact word appear?"

it asks:

"Which piece of text has a meaning most similar to this query?"

This is where embeddings come into the picture.

The document chunks are converted into vectors, and the user's query is also converted into a vector.

The system then compares the query vector with the chunk vectors, commonly using cosine similarity.

Text → Embedding → Vector

Query vector ↔ Chunk vectors

This means the wording doesn't always have to be identical.

For example:

"What technologies do you work with?"

could be semantically related to:

"Skills: Python, JavaScript, Azure, Docker..."

even though the wording isn't exactly the same.

Semantic search is therefore useful for:

• Meaning

• Context

• Similar concepts

• Different ways of asking the same question

• Synonyms and paraphrasing

The quality of this retrieval also depends on the embedding model.

3. Hybrid Search — Meaning + exact terms

Hybrid search combines the two signals.

Keyword signal
       +
Semantic signal
       ↓
Combined relevance
       ↓
Ranked chunks

Keyword search provides precision around explicit terms, while semantic search provides contextual understanding.

For example:

"Python skills used in cloud projects"

contains both:

• a specific term: Python

• contextual intent: skills used in cloud projects

In my learning implementation, I experimented with:

hybrid_score =
    0.7 × semantic_score +
    0.3 × keyword_score

These weights are not a universal rule. They are simply part of my experiment. In a real application, the appropriate balance would depend on the documents and queries being handled.

Document extraction and chunking can have a significant effect on what retrieval eventually sees.

What I learned

1. Semantic search isn't just "search with AI"
   It is a different retrieval mechanism based on embeddings and vector similarity.

2. Keyword search is still useful
   Embeddings don't make keyword search obsolete. Exact terms such as technologies, company names, skills, and identifiers can be very useful retrieval signals.

3. Hybrid search isn't magic
   Hybrid retrieval combines complementary signals, but the result still depends on the query, corpus, chunking, embedding quality, ranking method, and weighting.

4. Scores need context
   A retrieval score tells me how the system ranked the available chunks. It doesn't automatically mean:

   "This is definitely the correct answer."

5. Retrieval is worth inspecting separately
   Before adding an LLM on top, I wanted to understand what was actually being retrieved.

   If the wrong context is retrieved, putting an LLM after it doesn't automatically fix the retrieval problem.

Attachments / images

I would include two visual attachments in the assignment:

Search Strategy / Architecture

Your existing infographic:

Attachment 2 — Application UI / Retrieval Results

Use the improved UI screenshot after the Three Ways to Search section, followed by your actual result screenshots.

This gives a nice progression:

1. What I wanted to learn ↓

2. Retrieval architecture ↓

3. Three search strategies ↓

4. Application UI ↓

5. Same query → different results ↓

6. What I learned On

Conclusion

Choosing the right search strategy depends on what your application needs to understand.

• Keyword Search works best when exact terms, names, IDs, or precise matches are important.

• Semantic Search focuses on meaning and intent, making it useful when users express the same idea in different words.

• Hybrid Search combines keyword and semantic approaches, helping balance exact matching with contextual understanding.

In practice, there is no single search strategy that fits every use case. Keyword search provides precision, semantic search provides contextual relevance, and hybrid search brings both strengths together. The best approach depends on your data, query patterns, and the type of results your users expect.

In volatile markets, delayed decisions can lead to missed opportunities or losses.

While there are many tools that provide alerts and notifications, I wanted to build something lightweight, customizable, and tailored to my needs.

So I built a real-time market monitoring system using n8n.

Problem Statement

I needed:

• Real-time price tracking (Nifty, Crude Oil)

• Daily important announcements (NSE)

• Noise-free alerts

• One single consolidated notification

Most tools either:

• Send too many alerts ❌

• Lack customization ❌

• Or are paid ❌

Solution Overview

I designed a workflow that:

• Fetches market data from Yahoo Finance

• Pulls announcements from National Stock Exchange of India

• Applies filtering + logic

• Sends alerts via Telegram

Architecture

n8n workflow architecture for real-time market alerts

The workflow runs on a Cron schedule and uses parallel branches:

Cron
 ├── NSE RSS Flow
 ├── Nifty Price Flow
 └── Crude Oil Flow
        ↓
     Merge
        ↓
   Final Alert

Key Features

1. Market Data Tracking

• Nifty & Brent Crude via Yahoo Finance API

• Calculates % change vs previous close

• Detects bullish 📈 / bearish 📉 signals

2. NSE Announcements (First-Run Logic)

• Fetches RSS feed

• Runs only once per day

• Filters out:

  • Mutual Funds

  • ETFs

  • irrelevant entries

3. Smart Filtering

• Threshold-based alerts (e.g. >1%)

• Avoids noise and duplicate alerts

4. Aggregated Notification

Instead of multiple alerts:

👉 Everything is merged into one structured message

Alert Example

📊 Market Alert

NIFTY: +1.2% 📈
Crude Oil: -0.8% 📉

📰 NSE Updates:
• Company X result announced
• Merger news

Why I Chose n8n

Instead of building a full microservice:

• Faster setup

• Visual workflow

• Easy integration

• Flexible logic

👉 Perfect for rapid prototyping and automation

Challenges Faced

• JSON parsing issues in HTTP node

• Telegram SSL issue in Docker

• RSS feed returning limited data

• Handling first-run logic correctly

Learnings

• Automation can replace repetitive monitoring

• Simpler architecture > over-engineering

• Data filtering is more important than data fetching

Conclusion

This project started as a small experiment but turned into a very practical tool.

It helps:

• React faster to market changes

• Reduce noise

• Stay focused on important signals

Resources

• Yahoo Finance API

• NSE RSS Feed

• n8n workflow automation