Wipro Gen AI interview questions & answers

Good morning sir. My project is an enterprise RAG chatbot. Documents are parsed and chunked, embeddings go into a vector database, and when a user asks a question we retrieve the relevant chunks and the LLM generates a grounded answer. We also added an agent layer for tool calling.

Four techniques. One, query rewriting — a light LLM step that rephrases or breaks a messy question into clear sub-questions before searching. Two, HyDE — hypothetical document embeddings. The LLM first writes a hypothetical answer, we embed that answer, and search with it. Three, hybrid search — dense vector search for meaning, plus sparse keyword search like BM25 for exact terms like acronyms, IDs or legal words, and we combine both using reciprocal rank fusion. Four, reranking — fetch a bigger pool, like the top 50, and pass them through a cross-encoder like Cohere Rerank or BGE reranker to pick the final top-K.

First, I will confirm it really is a generation issue — check context precision and recall with RAGAS, to make sure the facts are actually in the chunks. Second, check the chunk order. LLMs pay more attention to the beginning and the end of a long prompt — the "lost in the middle" problem. So I will put the highest-scoring chunks at the top or bottom. Third, audit the prompt template — use clear tags like context, so the model doesn't confuse retrieved text with instructions. Fourth, lower the temperature to around zero and adjust top-P for factual extraction. And finally, test with a bigger or stronger model to see if it's a model capacity issue.

Prompt injection is when user input has hidden malicious instructions — to override the system prompt, break safety rules, leak the system instructions or misuse tools. I will use defense in depth. Input validation — strip harmful tags, limit length, and run inputs through a moderation classifier like Llama Guard. Structural separation — keep system instructions and user input separate, not just joined as one string. Least privilege on tools — like read-only database views, and human confirmation for any action with side effects. And output guardrails — check the output for PII leaks or system prompt leakage before returning it.

Three options. Sliding window — keep only the last N turns, like the last 5. Summarization — a background LLM regularly converts older turns into a short running summary added to the system prompt. And vector-based memory — store past conversations in a vector database and retrieve only the relevant old turns based on the current topic.

Sure. I take the URL, max retries like 5, and an initial delay of 1 second. In a loop, I call requests dot get with a timeout and raise for status. If it succeeds, I return the JSON. If it fails, I print the attempt, and if it is the last attempt, I raise an error. Otherwise I sleep for the delay and double it — 1, 2, 4, 8 seconds. And I will mention — in production, I add random jitter to the delay, so many clients don't retry at the exact same time.

I will make a class with a dictionary. For the key, I normalize the prompt — strip and lowercase — and take a SHA-256 hash. Get returns the cached response for that key, and set stores the response. So the first time it's a cache miss and we call the LLM; the second time the same question is a cache hit. Lookup is O of 1. And in production, I would replace exact matching with a semantic cache, like Redis or GPTCache, using embedding similarity, so even rephrased questions get a cache hit.

I will write a function that takes the API function, max retries, a base delay and a backoff factor. In a loop, it calls the API. If it fails, it logs the warning, and if the max retries are reached, it raises the error. Otherwise it sleeps and multiplies the delay by the factor. The max retry limit is important so we never get an infinite loop.

No sir, it should not. 400 means the request or prompt is wrong, and 401 means authentication failed. Retrying will give the same error, waste compute and use up the rate limit. We should retry only for temporary errors — 429 rate limits and 502, 503, 504, or network failures. So I will catch client errors separately and fail immediately.

Then I will add full jitter — the wait time becomes a random value between zero and the calculated delay, with a max cap like 16 seconds. Otherwise, during a small outage, thousands of workers retry at exactly the same moment and overload the server again. That is the thundering herd problem.

I normalize the query — lowercase, trim and remove extra spaces — and hash it with SHA-256 as the key. Before calling the LLM, I check the cache; if found, I return it immediately.

Two problems. First, it is volatile — when the container restarts, the cache is gone. Second, in production we run many pods, like on Kubernetes, and each pod has its own separate cache, so we still get duplicate LLM calls. The fix is a central cache like Redis, with an LRU eviction policy to control memory.

No. Real-time questions like a stock price, or personalized ones like a greeting for a specific user, should not be cached blindly. Static knowledge, like "explain backpropagation," can be cached for a long time, like 30 days. Semi-static content, like HR policies, can have a medium TTL like 24 hours, plus invalidation when the document changes. Real-time data — no cache at all. Personalized answers — cache with user ID in the key, and a short TTL like 15 minutes.

I will write a sliding-window chunker with chunk size and chunk overlap. First I check that overlap is smaller than chunk size, otherwise it will loop forever. Then I start at zero, take text from start to start plus chunk size, add it to the list, and move start forward by chunk size minus overlap. Overlap is needed because chunking creates artificial boundaries. If a subject is in chunk A and its action is in chunk B, both pieces lose meaning. Overlap keeps that continuity.

No. It can cut sentences or code in the middle of a word. Recursive splitting is better — split by paragraphs first, then lines, then words, then characters. Or semantic chunking — split only where the meaning between sentences changes a lot.

That is a real issue — high similarity doesn't mean different information. Five near-duplicates just waste the context window. So I will use two-stage retrieval. Stage one, over-retrieve — like the top 30 — using fast ANN search for high recall. Stage two, pass them through a cross-encoder reranker, or use MMR — maximal marginal relevance — which rewards relevance but penalizes repeated content. Then send the top 5 diverse and relevant chunks.

First, I use a regex to extract the JSON part — either from inside the markdown code block or from the first opening brace to the last closing brace. Then I parse it with json dot loads inside a try-except, and raise a clear error if it fails.

Three steps. One, schema enforcement with Pydantic — so we check the structure and data types, not just valid JSON syntax. For example, sentiment must be positive, negative or neutral, and the confidence score must be between 0 and 1. Two, a self-correction loop — send the bad output and the exact validation error back to the LLM and ask it to fix it. Three, after N failed attempts, log it, raise an alert, and return a structured fallback response, so the upstream service stays stable.