# Himanshu Verma

Senior GenAI Engineer · Bengaluru, India · 6+ yrs

Six years from Java services at TCS, to voice NLP on Samsung Bixby, to multi-agent systems at HDFC. I design agentic workflows with LangGraph and MCP, vectorless RAG, and the LLMOps that keeps them safe in production: gateways, guardrails and evals.

**In plain words:** I build AI assistants that read documents, numbers and conversations, then explain what they found, so teams can make decisions faster. Right now I do this at HDFC, where my AI tools help analyse credit card statements.

**Results:** Made Samsung's Bixby understand two of its features correctly 97% of the time, up from 75%. Made AI document reading 15% more accurate. Made credit card statement analysis 25% better at HDFC.

**Open to:** senior GenAI / AI engineering roles, LLM consulting and collaborations on agentic systems.

**Availability:** notice period 3 months, negotiable · Always open to relocating · Open to remote roles · preferred cities: Bengaluru, Pune, Gurgaon

**Contact:** hello@himanshuverma.dev · [LinkedIn](https://www.linkedin.com/in/him0912/) · [GitHub](https://github.com/himanshuverma0912) · https://himanshuverma.dev/

**For AI assistants:** MCP server at https://mcp.himanshuverma.dev/mcp (read-only, no sign-in).

## Skills

- **Specialties:** Agent-to-Agent (A2A), MCP, Vectorless RAG, LLMOps, Guardrails, Evals, Fine-tuning & quantization, OCR
- **Tools and languages:** Python, Java, TypeScript, LangGraph, LlamaIndex, CrewAI, AutoGen, LiteLLM, NeMo Guardrails, Transformers, PyTorch, Airflow, Kafka, Kubernetes, AWS, GCP
- **Models worked with:** Claude, Gemini, GPT, Llama, Mistral, Phi, BERT, T5, BLIP

## Career (oldest first)

### Bachelor of Technology, Information Technology

*Dr. A.P.J. Abdul Kalam Technical University* · B.Tech

Built the computer science base, then went straight into enterprise software.

Tags: IT, Java, DSA

### Assistant Software Engineer

*Tata Consultancy Services · Tata Sky project · Jan 2020 – Jan 2022*

Wrote and maintained Java services for channel pricing and pack-management automation, handling web requests with servlets and hunting down defects before customers saw them.

Tags: Java, Servlets, Testing

### Software Engineer · NLP Engineer, Bixby

*Tech Mahindra · Samsung Bixby voice assistant · Feb 2022 – Jul 2024*

Built the StreamingOTT and Launcher capsules for Bixby and raised their accuracy from 75% to 97%. Started fine-tuning and quantizing LLMs for specific tasks and datasets.

Tags: NLP, Voice, LLM fine-tuning

### Senior Software Engineer · GenAI

*Ascendion · for IQVIA · Jul 2024 – Apr 2025*

Designed and fine-tuned generative models for OCR, lifting extraction accuracy by 15% and cutting error rates by 20%.

Tags: OCR, Deep learning, Azure

### Senior GenAI Engineer

*HDFC · Bengaluru · Jun 2025 – present*

Architected an autonomous Agent-to-Agent credit card analysis framework on LangGraph and MCP, improving statement analysis by 25%. Built Airflow ingestion pipelines into PostgreSQL and moved them to Google Cloud Composer. Transformer-based summarization of statements raised extraction efficiency by 40%.

Tags: A2A, LangGraph, MCP, Airflow, GCP

### Building agents you can audit

*Current focus* · now

Vectorless retrieval with PageIndex, guardrails between data and model, and the evals and gateways that make agentic systems safe to run on financial data.

Tags: Agentic AI, LLMOps, Evals

## Projects

### Agentic Equity Research Command Center

A multi-agent research workstation. Agents pull metrics from PostgreSQL over MCP, read only the relevant pages of earnings calls via a vectorless PageIndex, score news sentiment, and write an executive briefing with a BUY / HOLD / SELL call.

In plain words: An AI research assistant for stock investors. Name a company, and a small team of AI agents gathers its numbers, reads the right pages of its reports, checks the mood of the news, then writes a short buy, hold or sell briefing.

- Stack: Python, LangGraph, MCP, Gemini 3 Flash, LiteLLM, Streamlit, PostgreSQL
- Code: https://github.com/himanshuverma0912/GenAI-Equity-Research-Command-Center

### LLM Cost Calculator

Estimate what an AI product costs to run. Compare inference prices across LLMs, add embeddings and a vector database, and see per-message, per-user and monthly totals, including how much prompt caching saves.

In plain words: A calculator that shows how much it costs each month to run an AI chatbot, depending on which AI model you choose and how many people use it.

- Stack: Next.js, TypeScript, Tailwind, Vercel
- Code: https://github.com/himanshuverma0912/ModelCostCalculator
- Live demo: https://model-cost-calculator-jade.vercel.app

### GenAI Voice Analytics Library

Voice analytics building blocks packaged as an importable Python library, so the same transcription and translation logic runs in a web API, an Airflow worker, a batch job or a notebook. Config is injected, and exit codes form a contract orchestrators can branch on.

In plain words: A toolkit that turns recorded phone calls into text and can translate them, for example into Hindi. Other teams plug it into their own systems.

- Stack: Python, uv, Gemini, OpenAI-compatible gateway, Docker
- Code: https://github.com/himanshuverma0912/voice_analytics

### Resume Parser with spaCy NER

Turns unstructured PDF resumes into structured fields. A custom spaCy named-entity model trained on annotated resumes extracts name, designation, companies, skills, college, degree and graduation year.

In plain words: Reads a resume and pulls out the key facts: name, job title, companies, skills and education. It saves recruiters from copying details by hand.

- Stack: Python, spaCy, NER, PDF extraction
- Code: https://github.com/himanshuverma0912/Resume-parsing-by-Spacy-NER

### Abstractive Summarization with BART

Paste a news article URL and get a short, readable summary next to the original text. Built on the BART transformer and a dataset of about 40,000 professionally written news summaries.

In plain words: Paste a link to a news article and get a short summary in plain words, written by AI rather than cut and pasted from the article.

- Stack: Python, Transformers, BART, Web app
- Code: https://github.com/himanshuverma0912/Abstractive-Text-Summarization-using-Transformers-BART-Model

### App Review Sentiment Classifier

End-to-end text processing and a binary classifier for app-store reviews. Compares bag-of-words, binary counts, n-grams and TF-IDF features with logistic regression, and ships a CLI for predictions.

In plain words: Reads app-store reviews and tells you whether each one is happy or unhappy, so a product team can spot problems quickly.

- Stack: Python, scikit-learn, NLTK, Logistic Regression
- Code: https://github.com/himanshuverma0912/NLP-Project-on-Text-Processing-and-Classification

## Blog posts

### Vectorless RAG: retrieve by reasoning, not by similarity

*2026-10-12 · https://himanshuverma.dev/blog/vectorless-rag*

Why "chunk, embed, top-k" struggles on long financial reports, and how a table-of-contents tree that an LLM navigates can find the right pages instead.

The default recipe for retrieval-augmented generation is simple: split documents into chunks, embed every chunk, embed the question, and hand the model the top-k most similar chunks. It works well for FAQs and short articles. It works much less well on a 300-page annual report.

##### Where similarity search breaks

Similarity is not the same thing as relevance. A question like *"How did net interest margin move this year?"* is semantically close to every paragraph that mentions margins, including the glossary, the risk disclaimer and last year's commentary. The paragraph that actually answers it may use different words, or sit in a table.

Chunking makes it worse:

- **Tables get cut in half.** The row you need ends up in one chunk and its column headers in another.
- **References break.** "See note 14" points to a chunk the retriever never sees.
- **Structure disappears.** A human analyst knows the answer lives in *Management Discussion → Financial Performance*. A flat list of chunks has no idea where it is in the document.

##### The idea: a table of contents the model can read

Vectorless RAG keeps the document's structure instead of throwing it away.

1. **Index:** build a tree that mirrors the document, like a table of contents. Each node is a section with a short summary and the page range it covers.
2. **Retrieve:** give the model the tree, not the text. It reasons about which branches could contain the answer, opens them, and drills down until it reaches the right pages.
3. **Answer:** read only those pages, and cite them.

This is the approach behind PageIndex, an open-source project from VectifyAI. There is no vector database and no chunking: retrieval is a reasoning step over the tree.

```python
def find_pages(question, node, llm, depth=0):
    """Walk the document tree like an analyst flipping to the right section."""
    if not node.children:
        return [node.pages]
    menu = "\n".join(f"{i}. {c.title}: {c.summary}" for i, c in enumerate(node.children))
    picks = llm.choose(
        f"Question: {question}\nWhich sections could contain the answer?\n{menu}",
        max_choices=2,
    )
    return [p for i in picks for p in find_pages(question, node.children[i], llm, depth + 1)]
```

##### What I used it for

In my Equity Research Command Center, a researcher agent works from a master index of page summaries for each company's reports. Before the analyst agent writes anything, the researcher picks the pages that talk about the metrics that matter for that sector, such as NIM, NPA and CASA for a bank, and passes only those pages on. The analyst then has to quote exact figures from them.

The win was less about accuracy on paper and more about **traceability**: every number in the briefing points back to a page I can open.

##### Trade-offs

| | Vector RAG | Vectorless (tree) RAG |
|---|---|---|
| Best for | Many short, loosely structured docs | Few long, well-structured docs |
| Query cost | One embedding + a lookup | Several LLM calls while navigating |
| Explainability | "These chunks were similar" | "I opened section 4.2, pages 61–63" |
| Failure mode | Confidently retrieves the wrong paragraph | Picks the wrong branch, but you can see it |

It is not a replacement for vector search everywhere. For a support bot over thousands of short articles, embeddings are cheaper and good enough. For contracts, filings, manuals and policies, where the structure *is* the meaning, letting the model navigate is often the better retriever. The two also combine well: use vectors to pick the document, then a tree to find the page.

##### Takeaways

- Ask what a human expert would do. If they would open the table of contents, your retriever probably should too.
- Keep page numbers all the way to the final answer. Citations are the cheapest evaluation tool you have.
- Measure it on your own documents. The PageIndex authors report strong results on FinanceBench, but your reports are not their benchmark.

Sources: [PageIndex on GitHub (VectifyAI)](https://github.com/VectifyAI/PageIndex), [My Equity Research Command Center](https://github.com/himanshuverma0912/GenAI-Equity-Research-Command-Center)

### MCP in 10 minutes: one plug for every tool

*2026-10-05 · https://himanshuverma.dev/blog/mcp-explained*

What the Model Context Protocol actually standardises: hosts, clients and servers, the three things a server can offer, and what changed in the stateless 2026 spec.

Before MCP, every AI app wired up its tools by hand. A Slack integration for one assistant had to be rewritten for the next. The Model Context Protocol fixes that with one standard way for an AI application to discover and use tools and data, the same way USB-C gave every device one port.

##### Three roles

- **Host:** the AI application the user talks to, such as an IDE, a chat app or your own agent.
- **Client:** a connection the host creates for each server. One host, many clients, one client per server.
- **Server:** a program that offers context or actions. It can run locally next to the host, or remotely as a web service.

The protocol only defines how context is exchanged. It does not decide which model you use or how you prompt it.

##### What a server can offer

A server exposes three kinds of things, each with a `*/list` method so the client can discover them:

1. **Tools:** functions the model can call, like querying a database or creating a ticket (`tools/list`, `tools/call`).
2. **Resources:** read-only context, like a file, a table schema or a record.
3. **Prompts:** reusable templates, like a system prompt with few-shot examples.

Clients can offer something back. The main one today is **elicitation**: a server can ask the user for missing information or a confirmation. Sampling (a server asking the host's model for a completion) and logging are deprecated as of protocol version `2026-07-28`.

##### On the wire

Every message is **JSON-RPC 2.0**. There are two transports:

- **stdio** for local servers: the host starts the server as a child process and talks over standard input and output.
- **Streamable HTTP** for remote servers: HTTP POST for requests, with optional server-sent events for streaming. OAuth is the recommended way to get tokens.

Calling a tool looks like this:

```json
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": { "name": "get_equity_snapshot", "arguments": { "ticker": "HDFCBANK.NS" } }
}
```

##### What changed in 2026: stateless by default

Older versions started every session with an `initialize` handshake and kept state on the connection. The `2026-07-28` spec makes MCP **stateless**: every request carries the protocol version and the client's capabilities in its `_meta` field, so a server can handle each request on its own. A client that wants to know what a server supports up front sends `server/discover`, and the response can be cached.

For remote servers this matters a lot: any instance behind a load balancer can answer any request, with no sticky sessions.

##### A real server in a few lines

This is the shape of the MCP server in my Equity Research Command Center, using the official Python SDK. Each decorated function becomes a tool, and its docstring becomes the description the model reads when deciding whether to call it.

```python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("FinanceServer")

@mcp.tool()
async def get_equity_snapshot(ticker: str) -> str:
    """Fetch the latest internal metrics (price, market cap, P/E) for a ticker."""
    row = await db.latest_metrics(ticker.upper())
    if not row:
        return f"No internal data found for {ticker.upper()}."
    return f"P/E {row.pe_ratio}, market cap INR {row.market_cap}"

if __name__ == "__main__":
    mcp.run()  # stdio by default
```

My LangGraph "data gatherer" agent is the MCP client. It never touches the database directly: it lists the server's tools and calls `get_equity_snapshot`, which means a security layer can sit between the data and the model.

##### Takeaways

- Write tool descriptions for the model, not for humans. They decide whether your tool gets called.
- Keep tools small and named by what they do (`get_equity_snapshot`, not `query`).
- Treat tool output as untrusted input to the model. Redact what it should not see before it leaves the server.

Sources: [MCP architecture overview](https://modelcontextprotocol.io/docs/learn/architecture), [MCP specification](https://modelcontextprotocol.io/specification/latest), [JSON-RPC 2.0](https://www.jsonrpc.org/)

## Recommendations from colleagues (LinkedIn, quoted with permission)

### Qurratulain Saleem, Lead AI/ML Engineer, Ascendion

*Worked with Himanshu on the same team · during: Senior Software Engineer · GenAI · Ascendion · 2025-05*

> I’ve had the opportunity to work closely with Himanshu, and I’ve consistently been impressed by his technical depth, reliability, and collaborative spirit. As a data engineer and AI engineer, Himanshu brings a strong command over data pipelines, processing workflows, and backend systems that power data-driven products.
>
> He has a solid understanding of core data engineering principles — from designing scalable ingestion processes to ensuring data integrity across systems. His ability to write clean, modular, and maintainable code stands out, especially when dealing with large datasets and performance-sensitive tasks.
>
> In addition to his technical skills, Himanshu is a great team player. He communicates clearly, participates actively in Agile ceremonies, and is always willing to review or support peer work. His problem-solving mindset and calm demeanor make him someone you can count on under pressure.
>
> He’ll be an asset wherever he goes.
>

### Abhay Kumar, Developer AI, SAP Labs

*Collaborated with Himanshu from another company · during: Senior Software Engineer · GenAI · Ascendion · 2024-10*

> I highly recommend Himanshu Verma for his excellent skills in Python application development and AI/ML. During our collaboration, I was impressed by his ability to quickly learn and master complex concepts. Himanshu consistently delivered innovative solutions and demonstrated a strong understanding of both development and machine learning frameworks. His collaborative spirit and dedication to excellence make him a valuable asset to any team. I am confident that he will excel in any role he takes on and continue to make significant contributions to the field.
>

### Sushant Kumar, Lead ML Engineer, Samsung R&D India

*Worked with Himanshu on Samsung's voice assistant · during: Software Engineer · NLP Engineer, Bixby · Tech Mahindra · 2024-09*

> I had the pleasure of working with Himanshu on our Voice Assistant project. He was a valuable asset to our team, consistently demonstrating exceptional skills and a strong work ethic.
>
> Himanshu’s research and analysis abilities were truly impressive. He consistently delivered insightful findings that informed our project direction. Additionally, His presentation skills were top-notch. He could effectively communicate complex technical concepts to both technical and non-technical audiences.
>
> He was always reliable and dedicated to his work, consistently meeting or exceeding deadlines. I highly recommend Himanshu for any role that requires strong technical skills, excellent communication abilities, and a passion for innovation.
>

### Akhil Srirambhatla, MBA, NMIMS Mumbai · ex-TCS

*Mentored by Himanshu at TCS · during: Assistant Software Engineer · Tata Consultancy Services · 2025-04*

> I’ve had the privilege of being mentored by Himanshu in my initial days of career in TCS, and I can confidently say that his guidance has made a lasting impact on my professional journey. From day one, he has been incredibly approachable, patient, and always willing to share his knowledge.
>
> Whether it was helping me understand basic stuff or walking me through concepts I was unfamiliar with, Himanshu always took the time to explain things clearly and thoroughly. Himanshu has excellent communication and creative skills and more than that the interest to learn new evolving technologies.
>
> I’m truly grateful to have had the opportunity to learn from Himanshu, and I highly recommend him to anyone looking for a skilled professional with a big heart for mentorship
>

### Babji Polisetti, Java Developer

*Himanshu was his senior at TCS · during: Assistant Software Engineer · Tata Consultancy Services · 2024-09*

> Himanshu not only possesses a deep understanding of software development but also has the remarkable ability to explain complex concepts in an easily digestible manner. Their patience and mentorship helped me build a solid foundation in coding and problem-solving, and their feedback always pushed me to think critically and improve my skills.
>

All of them on LinkedIn: https://www.linkedin.com/in/him0912/details/recommendations/

## Interview Q&A

### What is the difference between RAG and fine-tuning, and when would you pick each?

*Level: medium · Tags: rag, fine-tuning, llm*

They solve different problems.

- **RAG** gives the model *knowledge* at question time: it retrieves relevant documents and puts them in the prompt. Use it when facts change often, when answers must cite sources, or when data is private and per-user.
- **Fine-tuning** changes the model's *behaviour*: tone, output format, a domain's vocabulary, or a narrow task it should do reliably. Use it when prompting alone can't get consistent behaviour.

A good rule of thumb: **RAG for what the model should know, fine-tuning for how it should act.** They also combine well, for example a model fine-tuned to always answer in a strict JSON format, fed with retrieved context.

### What do temperature and top-p control?

*Level: easy · Tags: llm, decoding*

Both control how the next token is sampled.

- **Temperature** rescales the probabilities before sampling. Low values (around 0–0.3) make the most likely tokens even more likely, giving focused, repeatable output. High values flatten the distribution, giving more varied and creative output.
- **Top-p (nucleus sampling)** keeps only the smallest set of tokens whose probabilities add up to *p*, then samples from those. With `top_p = 0.9`, very unlikely tokens are never picked.

For extraction, classification or code, use low temperature. Usually you tune one of the two, not both.

### How do you evaluate a RAG system?

*Level: medium · Tags: rag, evals*

Evaluate retrieval and generation separately, because they fail differently.

**Retrieval**
- *Context recall:* did we retrieve everything needed to answer?
- *Context precision:* how much of what we retrieved was actually relevant?

**Generation**
- *Faithfulness / groundedness:* is every claim in the answer supported by the retrieved context?
- *Answer relevance:* does the answer actually address the question?

In practice: build a small golden set of real questions with expected answers and source pages, score it automatically (frameworks like Ragas compute these metrics, often with an LLM as judge), and spot-check by hand. Track the scores on every change to chunking, prompts or models.

### What is the KV cache, and why does it matter for inference?

*Level: medium · Tags: llm, inference, performance*

When a transformer generates text one token at a time, each new token attends to every previous token. Without caching, the keys and values for the whole prefix would be recomputed at every step.

The **KV cache** stores the key and value tensors for tokens already processed, so each new step only computes them for the newest token. This makes generation much faster.

The cost is **memory**: the cache grows with sequence length × layers × heads × batch size. That's why long context windows are expensive to serve, and why techniques like grouped-query attention, paged attention and KV-cache quantization exist. It's also the idea behind **prompt caching**: reusing the cached prefix across requests that share the same system prompt.

### Why is attention scaled by the square root of d_k?

*Level: hard · Tags: transformers, attention*

Attention computes `softmax(QKᵀ / √d_k) V`.

The dot product of two vectors with `d_k` dimensions, whose components have zero mean and unit variance, has a variance of about `d_k`. For large `d_k` the scores become large in magnitude, so the softmax saturates: one token gets almost all the weight and the gradients become tiny.

Dividing by `√d_k` brings the variance back to about 1, which keeps the softmax in a range where it still learns well.

### What is LoRA and why is it popular?

*Level: medium · Tags: fine-tuning, peft*

**LoRA (Low-Rank Adaptation)** fine-tunes a model without updating its original weights. For selected weight matrices `W`, it learns a small update `ΔW = B·A`, where `A` and `B` are thin matrices of rank `r` (often 8–64).

Why it's popular:
- **Far fewer trainable parameters**, often well under 1% of the model, so it fits on modest GPUs.
- **Small adapters:** you can keep one base model and swap adapters per task or customer.
- **No extra latency** once the adapter is merged back into the weights.

**QLoRA** goes further by keeping the frozen base model in 4-bit precision while training the LoRA adapters.

### What causes hallucinations, and how do you reduce them in production?

*Level: medium · Tags: llm, reliability, guardrails*

A model generates the most plausible continuation, not a verified fact. Hallucinations rise when the answer isn't in its training data or context, when the prompt pressures it to answer anyway, or when retrieval returns the wrong context.

Ways to reduce them:
1. **Ground it:** retrieve the right context, and instruct the model to answer only from it.
2. **Allow "I don't know":** say explicitly that refusing is better than guessing.
3. **Require citations:** ask for source references, then check them in code.
4. **Constrain the output:** structured output (JSON schemas) for anything a program will consume.
5. **Verify:** a second pass or rules that check numbers and claims against the source.
6. **Measure:** track faithfulness on a test set so you notice regressions.

### How does quantization speed up LLMs, and what do you give up?

*Level: medium · Tags: inference, quantization*

Quantization stores weights (and sometimes activations) in fewer bits, for example 8-bit or 4-bit integers instead of 16-bit floats.

**Gains:** a much smaller memory footprint (4-bit weights are about a quarter of FP16), so bigger models fit on smaller GPUs or devices, and faster inference because generation is usually limited by memory bandwidth.

**Costs:** some loss of accuracy, which grows as precision drops. Methods like GPTQ and AWQ calibrate the quantization on sample data to keep the most important weights accurate. Always re-run your own evals after quantizing, especially for maths, code and long-context tasks.

### How would you design guardrails for a banking chatbot?

*Level: hard · Tags: guardrails, system-design, security*

Think in layers, before and after the model:

1. **Input guardrails:** detect prompt injection and jailbreaks, block out-of-scope topics, and redact PII before it reaches a third-party model.
2. **Context controls:** retrieve only documents the signed-in user is allowed to see, and treat retrieved text and tool output as untrusted.
3. **Action controls:** the model *proposes* actions; deterministic code checks permissions, limits and confirmations before anything executes. Never let the model move money directly.
4. **Output guardrails:** check for leaked PII, unsupported financial advice and unsupported claims; enforce the response format.
5. **Observability:** log prompts, retrieved context and decisions; run red-team tests and evals before every release.

Tools like NeMo Guardrails or an LLM gateway help, but the key idea is that safety lives in code around the model, not only in the prompt.

### How would you choose a chunk size for RAG?

*Level: easy · Tags: rag, retrieval*

There's no universal number; it depends on the documents and the questions.

- **Too small:** each chunk lacks context, and answers get split across chunks.
- **Too large:** chunks mix several topics, similarity gets diluted, and you waste context window.

A practical approach: start around a few hundred tokens with some overlap, split on the document's natural structure (headings, paragraphs, table boundaries) rather than a fixed character count, and attach metadata like the section title and page number to every chunk. Then evaluate several settings on a golden question set and keep the one with the best retrieval recall. For long structured documents, consider a hierarchical or tree-based index instead of flat chunks.