Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
If you have read about RAG, you will probably be familiar with the concept of embeddings.
We take a bunch of text and turn it into numbers.
That's it.
But there is one more layer here.
There are different ways to represent text for retrieval.
Two important approaches are sparse representations and dense embeddings.
Let's understand how they work and when each one is useful.
Sparse Representations
Imagine you have a giant dictionary containing every word in your language. Let's say it has 50,000 words.
A sparse representation for a sentence can assign a value to each of those 50,000 words based on how relevant that word is to the sentence.
Most sentences only contain a small number of those words.
So, out of 50,000 possible positions, only a small number will have meaningful values. The rest will be zero.
That's why it's called sparse: most of the vector is empty, with only a few non-zero values.
Here is a simpler example.
Let's say our vocabulary contains just these 10 words, in this order:
[cat, dog, run, fast, food, eat, blue, sky, car, drive]
Now take the sentence:
"The dog can run fast"
The sparse vector could represent it like this:
cat dog run fast food eat blue sky car drive
0 1 1 1 0 0 0 0 0 0
It's essentially a representation of which words are present and how important they are.
Now take a second sentence:
"I like to eat food fast"
cat dog run fast food eat blue sky car drive
0 0 0 1 1 1 0 0 0 0
You can see that both vectors are mostly zeros.
This kind of representation works well when the exact words in the text matter.
But that also creates some limitations.
Where Sparse Representations Can Struggle
Synonyms
"buy" and "purchase" have similar meanings, but a traditional word-based representation can treat them as completely different terms.
Paraphrasing
Two people can ask the same question using completely different words, making it harder to connect them based on literal word overlap.
Conversational queries
Consider:
"Why is my package taking so long?"
and:
"Shipping delays explained"
There is very little literal word overlap, even though the second document could contain exactly the information the user needs.
This is where dense embeddings become useful.
Dense Embeddings
With sparse representations, we are largely looking at which words appear.
With dense embeddings, we are more interested in the semantic meaning of the text.
A dense embedding represents a piece of text as a relatively small vector containing many numerical values.
Instead of having thousands of mostly-zero positions corresponding to vocabulary terms, a dense vector might contain hundreds or thousands of values, with most of them being non-zero.
A simple example:
Sentence 1:
"The dog ran quickly"
Sentence 2:
"The puppy sprinted"
Look closely. These two sentences don't share a single word.
"Dog" ≠ "puppy."
"Ran" ≠ "sprinted."
If we only looked for matching words, these sentences could appear completely different.
Dense embedding models are trained to capture semantic relationships between text.
So these two sentences can end up with embeddings that are relatively close to each other because they express a similar idea.
This is one of the reasons dense embeddings are useful for semantic search.
But dense embeddings have their own limitations.
Where Dense Embeddings Can Struggle
Dense embeddings are designed to capture broader semantic relationships, but they may not be as effective when exact terms are important.
For example:
- Product codes such as
SKU-4471B - Exact names
- Error codes
- Rare technical terms
- Specific identifiers
A search for an exact product code may be better handled by a method that focuses on literal term matching rather than only semantic similarity.
Wrapping Up
Embeddings turn text into numbers, but there isn't just one way to do that.
Sparse representations preserve explicit lexical signals and are useful when exact terms matter.
Dense embeddings capture broader semantic relationships and are useful when the same idea can be expressed using different words.
Understanding this difference helps explain why RAG systems sometimes use more than one retrieval method instead of relying on dense embeddings alone.
Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.
I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.
Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.
Spend code review effort where business risk is highest — not spread evenly across every diff.
⭐ Star it on GitHub:
HexmosTech
/
LiveReview
Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.
The exact math, not a black box
Visualize blast radius at a glance
Every factor that feeds the score
Here's the goal:
- A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.
- A 300-line UI change in one file, fully covered by…
Click below to try LiveReview with your codebase:
Top comments (0)