I didn’t know then that a tiny spinning circle would give me the perfect sequel.

The Funny Little Circle

If you’ve used Claude Code — Anthropic’s CLI agent — you’ve watched it think. Or rather, you’ve watched it tell you that it’s thinking, through a spinner in your terminal. A little animated dot cycling endlessly while the model processes your request.

That spinner doesn’t just spin silently. It pairs the animation with a rotating verb: Computing… Brewing… Sculpting…

It’s a small detail. A UX flourish. But recently, the source code for Claude Code was briefly accessible online, and someone with good taste made note of something delightful buried in constants/spinnerVerbs.ts: 187 loading verbs, each one hand-picked to keep you company while the AI does its thing.

I collected them. And reading through all 187 felt less like auditing a codebase and more like reading a small, strange dictionary of what we think computation actually feels like.

A Vocabulary in Motion

The list starts predictably. Accomplishing. Computing. Processing. Generating. Sensible, functional, honest. These are the verbs of work.

Then things get culinary. Baking. Brewing. Caramelizing. Fermenting. Julienning. Flambéing. Sautéing. Marinating. There are more cooking verbs in this spinner than in some recipe apps. Whoever wrote this clearly believes that thinking and cooking share a fundamental rhythm — both are about applying the right kind of heat, for just the right amount of time, and waiting.

Then the list goes somewhere else entirely.

Boondoggling. Dilly-dallying. Lollygagging. Gallivanting. Frolicking. Moseying. Puttering.

These are words for doing nothing productively. Words your grandparents might have used to gently scold you. The spinner uses them unironically to describe an AI doing its most intensive work. I find that genuinely funny.

The Coined Words

Here’s where it gets interesting. Tucked among the real dictionary words are 22 invented or non-standard entries — verbs that don’t technically exist, or exist only in the loosest sense:

• Clauding — “Doing what Claude does.” The only self-referential entry. Coined specifically for this AI. There’s something endearing about a model having its own verb.
• Combobulating / Recombobulating — The reverse of discombobulate, which is itself a wonderfully absurd word. These don’t exist in any dictionary, but they feel right.
• Gitifying — Making something git-compatible. Pure tech slang elevated to loading-screen philosophy.
• Hyperspacing — Moving through hyperspace. A sci-fi metaphor for thinking really fast.
• Quantumizing — Applying quantum-level thinking. Vague, impressive-sounding, perfect.
• Shenaniganing — The verb form of shenanigans. A legitimate move.
• Tomfoolering — Clowning around, derived from tomfoolery. A word that should exist.
• Whatchamacalliting — Doing that thing whose name you can’t remember. Perhaps the most honest description of what LLMs occasionally do.
• Flibbertigibbeting — Behaving in a silly, flighty way. Seventeen letters. Used in a terminal spinner. Respect.
• Symbioting — Forming a mutually beneficial relationship. Coined from symbiosis.
• Beboppin’ — Jazz-inflected, contraction intact. The apostrophe is doing real work here.
• Wibbling — Wobbling slightly. British informal. Delightfully specific.

Reading these, you realize this wasn’t a task handed off to a script or a random word generator. Someone sat down and decided that an AI loading screen deserved invented words, borrowed jazz slang, and British informalism. That’s a creative decision, made by a human, about how a machine should speak.

The Full Cast

All 187, if you want the complete picture:

Accomplishing, Actioning, Actualizing, Architecting, Baking, Beaming, Beboppin’, Befuddling, Billowing, Blanching, Bloviating, Boogieing, Boondoggling, Booping, Bootstrapping, Brewing, Bunning, Burrowing, Calculating, Canoodling, Caramelizing, Cascading, Catapulting, Cerebrating, Channeling, Channelling, Choreographing, Churning, Clauding, Coalescing, Cogitating, Combobulating, Composing, Computing, Concocting, Considering, Contemplating, Cooking, Crafting, Creating, Crunching, Crystallizing, Cultivating, Deciphering, Deliberating, Determining, Dilly-dallying, Discombobulating, Doing, Doodling, Drizzling, Ebbing, Effecting, Elucidating, Embellishing, Enchanting, Envisioning, Evaporating, Fermenting, Fiddle-faddling, Finagling, Flambéing, Flibbertigibbeting, Flowing, Flummoxing, Fluttering, Forging, Forming, Frolicking, Frosting, Gallivanting, Galloping, Garnishing, Generating, Gesticulating, Germinating, Gitifying, Grooving, Gusting, Harmonizing, Hashing, Hatching, Herding, Honking, Hullaballooing, Hyperspacing, Ideating, Imagining, Improvising, Incubating, Inferring, Infusing, Ionizing, Jitterbugging, Julienning, Kneading, Leavening, Levitating, Lollygagging, Manifesting, Marinating, Meandering, Metamorphosing, Misting, Moonwalking, Moseying, Mulling, Mustering, Musing, Nebulizing, Nesting, Newspapering, Noodling, Nucleating, Orbiting, Orchestrating, Osmosing, Perambulating, Percolating, Perusing, Philosophising, Photosynthesizing, Pollinating, Pondering, Pontificating, Pouncing, Precipitating, Prestidigitating, Processing, Proofing, Propagating, Puttering, Puzzling, Quantumizing, Razzle-dazzling, Razzmatazzing, Recombobulating, Reticulating, Roosting, Ruminating, Sautéing, Scampering, Schlepping, Scurrying, Seasoning, Shenaniganing, Shimmying, Simmering, Skedaddling, Sketching, Slithering, Smooshing, Sock-hopping, Spelunking, Spinning, Sprouting, Stewing, Sublimating, Swirling, Swooping, Symbioting, Synthesizing, Tempering, Thinking, Thundering, Tinkering, Tomfoolering, Topsy-turvying, Transfiguring, Transmuting, Twisting, Undulating, Unfurling, Unravelling, Vibing, Waddling, Wandering, Warping, Whatchamacalliting, Whirlpooling, Whirring, Whisking, Wibbling, Working, Wrangling, Zesting, Zigzagging.

What This Is Really About

In my LinkedIn post, I was poking at how developer vocabulary has inflated — how simple acts get dressed up in grander language, sometimes to signal sophistication, sometimes just out of habit.

But this spinner list is something different. It’s not inflated language. It’s playful language. It’s the language of people who took a mundane UX problem — how do we tell the user we’re busy? — and decided to treat it as an opportunity for delight.

Schepping through your codebase. Osmosing context. Recombobulating after a bad merge. Clauding in the general direction of your problem.

The funny circle keeps spinning. And now you know every word it might say.

You can customize the spinner verbs yourself — Claude Code supports a spinnerVerbs setting that lets you replace or extend the list. Personally, I’m keeping Flibbertigibbeting.

All 187 Verbs & Meanings

A paper reading session on A-RAG: Scaling Agentic RAG via Hierarchical Retrieval Interfaces

We had a paper reading session this week on a February 2026 preprint out of USTC and Metastone Technology. The paper is called A-RAG (arxiv: 2602.03442) and it makes a surprisingly compelling case — not through algorithmic complexity, but through a disarmingly simple idea: stop building smarter retrieval algorithms and instead give the LLM a set of tools and let it figure out how to search.

This post is my attempt to decompress what we read, what we argued about, and what I think actually matters here.

The One-Sentence Version

A-RAG wraps three retrieval tools — keyword search, semantic search, and a chunk reader — inside a ReAct agent loop, and lets the model autonomously decide how to search, when to drill deeper, and when it has enough evidence to answer. That’s the whole idea. And it works surprisingly well.

Why This Is Interesting (Context First)

If you’ve been following the RAG space, you know it’s been a busy few years. The trajectory has roughly been:

1. Basic RAG (2021–2022): Chunk documents → embed them → retrieve top-k → stuff into prompt → generate.
2. Iterative/Conditional RAG (2023): Self-RAG, FLARE, IRCoT. Models decide when to retrieve, or follow predefined multi-step patterns.
3. Graph-Enhanced RAG (2024): GraphRAG, LightRAG, HippoRAG, RAPTOR. Richer knowledge structures — entity graphs, hierarchical summaries — to capture relationships that vector similarity misses.
4. RL-Trained Retrieval Agents (2025): Search-R1, R1-Searcher, RAG-Gym. Models trained via reinforcement learning to learn optimal retrieval strategies.
5. A-RAG (2026): Training-free agentic RAG. Forget the algorithm — just design good tools and trust the model.

(I covered the GraphRAG era in a previous post if you want the full backstory on why graph structures matter for multi-hop questions.)

What’s interesting about A-RAG is that it arrives at the end of this journey and somewhat deliberately sidesteps the complexity that accumulated along the way.

The Paradigm Taxonomy (Or: How the Paper Frames Everything)

The authors propose three paradigms for RAG, and this framing is doing a lot of work in the paper:

Paradigm 1 — Graph RAG: Single-shot retrieval, potentially with graph structures. The model has no control over the retrieval strategy. If the initial context is insufficient, there’s no recourse.

Paradigm 2 — Workflow RAG: Multi-step, but with predefined workflows. The model follows a fixed procedure — it can’t adapt its strategy, only execute the steps laid out in advance.

Paradigm 3 — Agentic RAG: The model has full autonomy. It chooses tools, adapts its strategy based on what it finds, and decides when to stop. This is what A-RAG claims to be.

They define “agentic” along three axes:

Full disclosure: we spent some time in the session debating whether this taxonomy is fair or self-serving. I’ll get to that.

What A-RAG Actually Does

Index Construction

Deliberately lightweight. Two offline stages:

• Chunking: ~1,000 token chunks aligned to sentence boundaries.
• Embedding: Sentence-level dense vectors via Qwen3-Embedding-0.6B, maintaining a sentence → parent chunk mapping.

No knowledge graph construction. No entity extraction. No summarization hierarchy. This is important — the paper’s whole point is that the agent loop can substitute for all that offline complexity.

The Three Tools

This is the heart of the system:

keyword_search(keywords, top_k) — Exact lexical matching. Scores chunks by counting keyword occurrences, weighted by keyword length (longer keywords score higher). Returns chunk IDs + sentence snippets. Best for entity names, specific terms, precise lookups.

semantic_search(query, top_k) — Dense retrieval using cosine similarity on sentence embeddings. Aggregates to parent chunks by max sentence score. Returns chunk IDs + matched sentences. Best for paraphrased queries, conceptual search, anything where exact wording varies.

chunk_read(chunk_ids) — Reads the full content of specified chunks. A Context Tracker prevents re-reading the same chunk (returns “already read,” saving tokens). This is the “drill down” tool.

The Key Design Insight: Progressive Information Disclosure

The search tools return snippets, not full chunks. The agent sees enough to decide whether a chunk is worth reading in full, but it has to explicitly call chunk_read to get the complete text. This creates a natural funnel: broad search → narrow snippets → selective full reads. The agent controls the signal-to-noise ratio at every step.

This is clever. And it’s why A-RAG (Full) uses fewer retrieved tokens than even Naive RAG while outperforming it — the model is efficient because the interface forces efficiency.

The Agent Loop

Standard ReAct. One tool call per iteration. No orchestration tricks. When max iterations is hit without an answer, it synthesizes from whatever evidence it gathered. The simplicity is intentional — the paper wants to isolate the effect of hierarchical interfaces from agent orchestration complexity.

The Numbers

Main results on GPT-4o-mini and GPT-5-mini (LLM-as-judge accuracy):

And the context efficiency comparison:

That middle row — A-RAG (Naive) — is the one that jumps out at me. When you give the agent only a single embedding search tool with no progressive disclosure, it retrieves 5–10× more tokens than Naive RAG and still performs worse than A-RAG (Full). The hierarchical interface isn’t just a nice-to-have; it’s what makes the approach work.

The Scaling Story

Two scaling experiments on MuSiQue:

More steps (5 → 20 max iterations): GPT-5-mini gains ~8%, GPT-4o-mini gains ~4%. Stronger models benefit more from longer reasoning horizons. Makes sense.

Higher reasoning effort (min → high): Both models gain ~25%. This is the bigger result. It directly connects to the test-time compute scaling trend — A-RAG becomes better simply by letting the underlying model think harder, without any architectural changes.

What the Failures Tell Us

On MuSiQue, 82% of A-RAG’s incorrect answers fail due to reasoning errors, not retrieval failures. Within that:

• 40% — Entity confusion (model reads the right chunk but gets confused by other entities in it)
• 28% — Wrong retrieval strategy
• 22% — Question misunderstanding
• 10% — Exceeded step budget

This is a significant paradigm shift in where the bottleneck lives. Naive RAG fails because it can’t find the right documents. A-RAG fails because it found the right documents but reasoned incorrectly. The problem moves from retrieval to reasoning — and reasoning is exactly what’s improving fastest in frontier models. So A-RAG’s failures should get cheaper over time without any changes to the system itself.

What We Argued About

No good paper reading session is complete without some productive disagreement. A few things we pushed back on:

“Is this really a paradigm shift, or just ReAct + better tools?”

Honestly? Probably the latter. The agent loop is textbook ReAct. The contribution is the interface design. But — and this is what I kept coming back to — that might actually be the insight. If tool design matters more than orchestration complexity, that’s an underappreciated and actionable finding. The paper’s framing is a bit grandiose, but the underlying point is real.

The self-serving taxonomy

The three agentic principles are defined in a way that makes A-RAG the only method to check all three boxes. MA-RAG and RAGentA both get partial credit, but they’re arguably more sophisticated multi-agent systems than the paper acknowledges. Worth reading those papers alongside this one.

Cost — the elephant in the room

This is the biggest gap in the paper. A-RAG uses up to 20 LLM calls per question. Naive RAG uses one. With GPT-5-mini at production scale, we’re potentially looking at 20-50× the inference cost. The paper reports retrieved tokens but not total inference tokens (including all the reasoning steps). For any real deployment, this matters enormously. The paper doesn’t address it, which feels like a significant omission.

Only closed-source models

All experiments use GPT-4o-mini and GPT-5-mini. No open-source baselines (Llama, Qwen, Mistral). The claim that “A-RAG benefits from stronger models” is probably true, but we have no evidence of whether smaller or open-source models can execute the agentic loop reliably. This limits the generalizability of the findings.

No RL-trained comparison

Search-R1, R1-Searcher, and RAG-Gym are mentioned in related work but never benchmarked. These are arguably the closest competing paradigm — training models to learn retrieval strategies end-to-end. The comparison would have been illuminating.

The Connection to Things I Find Interesting

A few things kept occurring to me during the session:

This is essentially closed-corpus Deep Research. OpenAI’s Deep Research, Gemini’s Deep Research, and Perplexity all do the same basic pattern — search, fetch, read, reason, repeat — but over the open web. A-RAG applies it to a private document corpus. For enterprise RAG, this framing is actually more useful than treating it as a pure retrieval problem. The question becomes: how do you build a Deep Research agent for your internal knowledge base?

The MCP angle is real. Anthropic’s Model Context Protocol standardizes exactly this kind of tool interface. A-RAG’s three tools could be expressed as MCP servers, making the system interoperable with any MCP-compatible agent framework. That’s a practical path to adoption that the paper doesn’t explore but that practitioners building systems today should think about.

The reasoning bottleneck is good news. If 82% of failures are reasoning errors, and reasoning is improving faster than retrieval, then A-RAG-style systems get better for free as the underlying models improve. That’s a nice property for a system that requires no training.

The Bottom Line

A-RAG makes a genuinely interesting argument: that the right way to improve RAG isn’t to build smarter retrieval algorithms, but to design better tool interfaces and let capable models figure out the strategy themselves. The results back this up — A-RAG (Full) is state-of-the-art on the benchmarks tested while using comparable or fewer retrieved tokens than simple baselines.

The gaps are real: no cost analysis, no open-source models, no RL comparison, questionable scalability of the keyword search to large corpora. But the core insight — progressive information disclosure via hierarchical tools — feels like something worth building on.

If you’re building RAG systems today, the practical takeaway is this: before you reach for GraphRAG or HippoRAG, ask whether giving a capable model the right search tools and a ReAct loop gets you most of the way there. Judging by this paper, the answer is probably yes.

Paper: “A-RAG: Scaling Agentic RAG via Hierarchical Retrieval Interfaces” — Du et al., USTC & Metastone Technology, Feb 2026. arxiv: 2602.03442. Code at github.com/Ayanami0730/arag

Until last year, I based my reading list on Goodreads / Reddit recommendations and added some book covers that I loved! This year, I decided to pick most of them from my bookshelf. Looking at my bookshelf, I felt overwhelmed, so I used AI to make a book list.

Glimpses from My Bookshelves and Input to Gemini Pro

Gemini did a pretty decent job of preparing a TBR for me. I threw in a few books that I had previously planned (or that were missing from the shelf), and here is the final list.

All the best for your 2026 reading goals! If you wish to follow along for my reviews / additional books, that I tend to add to this list; here is my notion page</a>.

All the best for your 2026 reading goals! here is Notion page, where I keep track of my reading status and reviews.

Appendix I

List of all books on my shelves.

OpenAI also included a short prompt to generate an Ocean Wave Simulation, along with the result. Here, I run the same prompt across three models — and GPT-5.2 didn’t fare well.

Models tested

1. GPT-5.2 itself (via Cursor Agent)
2. Gemini 3.0 Pro (Beta) — enabled for Enterprise customers
3. Gemini 3.0 Pro — enabled for the general public

Verdict

1. Overall, Gemini 3.0 Pro (general model) did a better job: it generated the output in one shot and has 3D depth.
2. GPT-5.2 messed up the CSS even after multiple follow-up prompts.

Screenshot from OpenAI blog post

Source: Introducing GPT-5.2

GPT-5.2 Thinking

Gemini-3.0 Pro (Beta) Thinking Enterprise

Gemini-3.0 Pro (Thinking)

Putting GraphRAG to test, knowing it’s worth and when to deploy it!

The battle between knowledge graphs and vector databases just got real. Here’s what 160 queries and rigorous evaluation revealed about the future of AI-powered search.

The Information Retrieval Revolution We Didn’t See Coming

Imagine asking an AI system: “What are the connections between reinforcement learning and robotics?”

A traditional RAG system might give you a decent answer based on document similarity. But what if that same system could understand that DeepMind’s research team led by David Silver worked on both AlphaGo (reinforcement learning) and later collaborated with Boston Dynamics on robotic applications, creating a web of knowledge that goes far beyond simple document matching?

That’s the promise of GraphRAG—and after putting it through the most rigorous evaluation I’ve ever conducted, I can tell you: We can’t ignore GraphRAG.

What Is GraphRAG, Really?

Before diving into the data, let’s establish what we’re talking about. Traditional RAG (Retrieval-Augmented Generation) works like this:

1. Document Chunking: Break documents into pieces

2. Vector Embedding: Convert text to numerical representations

3. Similarity Search: Find chunks most similar to your query

4. Generation: Feed retrieved chunks to an LLM for synthesis

GraphRAG takes this foundation and adds a crucial layer:

1. Knowledge Graph Construction: Extract entities, relationships, and concepts (although Microsoft’s original paper proposes to use LLMs, I wonder, why can’t we just use simple NER?!)

2. Entity Linking: Connect related entities across documents

3. Graph-Enhanced Retrieval: Use both vector similarity AND graph relationships

4. Multi-hop Reasoning: Traverse connections to find non-obvious insights (This is what we need to test!!)

Think of it as the difference between a library catalog (traditional RAG) and a research assistant who knows how every book, author, and concept connects to every other (GraphRAG).

P.S. Got this analogy from LLM (Gemini Pro 2.5)

The Experiment: 160 Queries, Zero Bias

We use LLM as a judge and it has the context of only query and the summary LLM generated

The Dataset: 1,000+ documents from diverse sources

• 550+ research papers from ArXiv and Semantic Scholar
• 250+ tech news articles from TechCrunch, VentureBeat, Wired
• 200+ GitHub repositories with AI/ML focus
• 500+ entities in our knowledge graph with rich interconnections

The Evaluation Framework

• 160 carefully crafted queries across 8 categories
• Blind LLM judge evaluation (Claude 3.5 Sonnet)
• 6 evaluation criteria: Completeness, Accuracy, Contextual Depth, Clarity, Relevance, Actionable Insights

Note: I added this to improve the data-set and queries. I used O3-mini for first 10-15 trials and then switched to Claude 3.5 as a judge

The Categories Tested

1. AI/ML Research - “Latest advances in transformer architectures”
2. Technical Deep Dive - “How does gradient descent optimization work?”
3. Industry Applications - “How are companies using federated learning?”
4. Comparative Analysis - “GraphRAG vs traditional RAG differences”
5. Future Directions - “What’s next for multimodal AI?”
6. Company Technology - “What AI research is Google focusing on?”
7. Cross Domain Connections - “Relationship between NLP and computer vision”
8. Research Trends - “Who are the key researchers in reinforcement learning?”

Decoding the Results

My initial thought was to use — (em-dash) instead of : (colon) in the above heading; side effects of using LLM too much!

These aren’t marginal improvements. These seemed consistent and assertive (at least for the experiment setup we did!)

Where GraphRAG Absolutely Dominates

The category breakdown reveals where GraphRAG excels:

The Criteria That Matter Most

Breaking down performance by evaluation criteria:

P.S. Note how traditional RAG always scores 7.5 (I felt it is a code bug somehow the summary of RAG systems always averaged out to 7.5. Will be triggering a few more tests to understand this behavior. Expect a part 2 of the article!)

Notice something interesting? GraphRAG doesn’t just win on technical metrics—it provides more relevant, actionable, and complete answers. This stems from the number of documents it was able to retrieve.

Judge Confidence: The Trust Factor

Perhaps most importantly, the AI judge was confident in its decisions:

• 45.6% of decisions made with high confidence (>80%)
• 54.4% of decisions made with medium confidence (60-80%)
• 0% low confidence decisions
• Average confidence: 78.2%

This isn’t just statistical noise—these are clear, reliable quality differences.

Sample Query and The Difference

Query: “What researchers are working on BERT and transformer models?”

Traditional RAG Response:

“BERT was developed by Google AI researchers including Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. The transformer architecture was introduced by Vaswani et al. in ‘Attention Is All You Need’…”

GraphRAG Response:

“The BERT and transformer research landscape involves several key researchers and institutions:

Google AI Team: Jacob Devlin (lead BERT researcher), Ming-Wei Chang, Kenton Lee, and Kristina Toutanova developed BERT. They built on transformer work by Ashish Vaswani, Noam Shazeer, and others.

Academic Collaborations: The original transformer paper came from Google Brain and Google Research, with contributions from University of Toronto (Aidan Gomez) and others.

Follow-up Research: Tom Brown (OpenAI) led GPT development, while Luke Zettlemoyer (University of Washington/Meta) worked on RoBERTa improvements.

Current Developments: Researchers like Colin Raffel (UNC/Google) are exploring T5 and unified text-to-text transformers, while Yann LeCun’s team at Meta investigates self-supervised learning applications…”

The Difference: GraphRAG understands that researchers move between institutions, collaborate across organizations, and that understanding these relationships provides much richer context.

Performance Considerations

• Query Latency: GraphRAG adds ~200ms overhead for graph traversal
• Storage: Knowledge graph requires ~2GB for 1000 documents (I could have optimized this with a few code tweaks)
• Accuracy: 7.62/10 vs 7.5/10 (minimal difference in factual accuracy)
• Completeness: 8.46/10 vs 7.5/10 (significant improvement in comprehensiveness)

When GraphRAG Fails (And Why That Matters)

These are some limitations I have identified (not comprehensive though!)

Where Traditional RAG Still Competes

1. Simple Factual Queries

Example: “What is the capital of France?”

• Traditional RAG: Fast, direct, accurate
• GraphRAG: Overkill with similar results

2. Highly Technical Deep Dives

Example: “Explain back propagation mathematics”

• Traditional RAG: Focused, detailed technical content
• GraphRAG: May add unnecessary context

3. Single-Document Answers

When: The answer lives in one specific document

• Traditional RAG: Efficient document retrieval
• GraphRAG: Graph overhead without benefit

The Trade-offs

The Future of RAG: What’s Next?

Based on these results, here’s where I see the field heading:

Hybrid Approaches Will Dominate

The future isn’t GraphRAG vs Traditional RAG—it’s intelligent routing:

• Simple queries → Traditional RAG
• Complex relationship queries → GraphRAG
• Mixed complexity → Hybrid approach

Dynamic Knowledge Graph Construction

Current GraphRAG requires manual graph construction. Next-generation systems will:

• Auto-generate knowledge graphs from documents
• Update graphs in real-time as new information arrives
• Learn optimal graph structures for specific domains

Multi-Modal Knowledge Graphs

Specialized Domain Graphs

The Bottom Line

GraphRAG isn’t just an incremental improvement—it’s a paradigm shift toward AI systems that understand relationships and context the way humans do. The 36% performance advantage we measured is just the beginning. (Results can vary based on data-set but consider it a win for this data-set at least!)

As knowledge graphs become easier to construct and maintain, and as AI systems become better at understanding relationships, GraphRAG will become the standard for any application requiring deep, contextual understanding.

The question isn’t whether GraphRAG is better than traditional RAG—our data proves it is for complex queries. The question is: Are you ready to implement it?

The Full Code, Dataset, Queries and Evaluations are available here in the GitHub repository

The future of information retrieval is relationship-aware, contextually rich, and powered by knowledge graphs. The question is: when will you make the jump?

Thanks for reading Not So Random Blog! Subscribe for free to receive new posts and support my work.

On a humid day, a seemingly simple yet deeply intricate image emerges. Crafted by an object we all turn to for solace - a fan or perhaps a simple window-adorned with a warm blanket, it stands as a silent sentinel against the oppressive heat.

The shadows it casts tell a different tale, woven by the reflections of nearby windows, the draping pants hanging from the balcony, and the gentle tinkling of decorative bells.

The Extraordinary in the Ordinary

Is there anything special about this scene? At first glance, perhaps not. Yet, like the quiet narratives Amitav Ghosh unearths, it holds within it a tapestry of stories. Each shadow, each reflection, is a whisper of a moment passed.

The blanket, a silent witness to nights seeking peaceful sleep, carries the hopes of beautiful dreams. In this still life, the mundane becomes magical, a testament to the unseen layers of everyday existence.

Sometimes the most profound stories are found not in grand gestures, but in these quiet daily glances that surround us - if only we pause long enough to truly see them.

At that moment, a wave of nostalgia washed over me, reminding me of a time when writing was not merely a task to be checked off but a fervent passion that flowed effortlessly from my pen. Each page was a time capsule, unfurling stories of my past self, my companions, and a myriad of ephemeral moments.

Among the scattered papers, I discovered meticulously handwritten notes on chemistry ⚗️, a subject that, despite its complexities, had once captivated my youthful mind. While the intricate details of textbook knowledge had long since receded into the depths of my memory, these scribbles acted as keys, unlocking the latent concepts buried within my subconscious. This serendipitous encounter with my former self ignited a spark within me.

Why Had I Stopped?

Why had I ever ceased to write with such abandon? The question lingered, urging me to reclaim that lost enthusiasm. And so, here I am, ready to embark on this rediscovered journey.

I would be remiss not to acknowledge the external influences that have played a pivotal role in rekindling my love for writing. The eloquent musings on Manassaloi’s blog and the thought-provoking posts on Substack have served as beacons, guiding me back to the path I once wandered with such joy and curiosity.

Thus, I set forth, with renewed vigor and an open heart, ready to weave new narratives and explore the vast landscapes of my imagination. Let this journey commence!