Generative AI Course in Pune with Placement

What an LLM actually is — at the level you need to build with one, not the level you need to publish a paper. Cover the transformer architecture (attention, positional encoding, layer norm, residual streams) at an intuition level, the difference between pre-training, instruction tuning, and RLHF / DPO, the model-family landscape (Claude, GPT, Gemini, Llama, Mistral, Phi, Qwen), and why specific models suit specific use cases (Claude for long-context analysis, GPT for general tasks, Gemini for multimodal, Llama / Mistral for on-prem and privacy). Plus the discipline that good AI Engineers practice — what a model is bad at, where hallucinations come from, and the cost / latency / quality triangle.

The week also fixes the vocabulary that the rest of the course leans on and that interviewers use as a filter: how AI, Machine Learning, Deep Learning and Generative AI actually nest inside one another, what a token is and why it is the unit you pay in, what a context window bounds, and what temperature and the other sampling parameters change about a response.

The module most GenAI courses skip entirely, and the one that separates an engineer who ships from an engineer who demos. Before any code, you learn to answer the question a hiring panel and a product owner both ask first: should this feature use an LLM at all? Many problems that look like AI problems are better solved by a database query, a rules engine or a form — and choosing the model anyway produces a system that is slower, more expensive and less reliable than the thing it replaced.

You work through a decision frame covering business value against cost, latency and reliability; where non-determinism is acceptable and where it is not; how to design a feature so a human reviews the output before it has consequences; and how to size an AI feature so it can be measured. The output of the week is a one-page AI feature brief for a real workflow, of the kind you will be asked to write in a product-engineering job and can talk through at interview.

Prompt engineering as a real engineering discipline, not magic incantations. Cover system prompts vs user prompts, few-shot prompting, chain-of-thought and the limits thereof, role / persona prompts (and why most production systems should not use them), JSON mode / structured output / Pydantic-AI for type-safe LLM responses, response constraints and validators, prompt versioning and A/B testing, and the discipline of writing prompts as code (in Git, with tests, with metrics). Hands-on with Claude, GPT, and Gemini APIs side-by-side so you internalise their differences.

The second half moves from writing a prompt to keeping it working: reusable prompt templates and patterns, prompt evaluation with test cases rather than impressions, and the iteration loop that turns a prompt that works once into a prompt that works on the hundredth input.

The applied half of prompting, aimed at the work that actually reaches a business. LLMs are used far more often for drafting, rewriting, summarising, translating and documenting than for anything exotic, and doing that well at professional quality is a distinct skill from calling the API. You work through ideation and drafting, summarisation and rewriting against a fixed brief, tone and register control, and long-document handling where the source will not fit in a single context window.

Developers get the parts that apply directly to engineering output — API and README documentation generated from source, release notes, technical explainers — with the standing rule that everything generated is a draft under review. The module closes on verification: how to check a summary against its source, and how to catch the fluent, confident, wrong paragraph that is the characteristic failure of this kind of work.

Where the model stops being a chat window and becomes a dependency in your application. Cover the chat-completions and responses API shapes across vendors, message roles and conversation state, streaming versus blocking calls and what each does to perceived latency, structured outputs and function-call payloads over the wire, and the error surface you must handle — rate limits, timeouts, truncated responses, content filters and transient 5xx.

The engineering discipline is the point: retries with backoff and idempotency, fallback models when the primary is degraded, request and response logging that is safe to keep, per-request token budgets, and configuration that lets you change model without changing code. You finish by adding a working AI feature to a small web application, wired the way a production service would be rather than the way a notebook is.

The retrieval half of retrieval-augmented generation. Cover sentence embeddings (sentence-transformers, BAAI BGE, OpenAI text-embedding-3, Voyage), the geometry of embedding space, vector databases (pgvector for SQL-native, Chroma for prototyping, Weaviate / Pinecone / Qdrant for scale), distance metrics (cosine, dot product, L2), HNSW indexing, hybrid retrieval (BM25 + dense + reranking with cross-encoders), and chunking strategies (fixed-size, semantic, parent-document). We finish with a small semantic-search service against a real corpus of your choice.

RAG is the dominant production GenAI pattern in Pune product engineering — and the pattern most poorly executed in the field. Cover the full pipeline: ingestion (PDFs, HTML, code, images via vision models), chunking, embedding, storage, query rewriting, retrieval, reranking, prompt assembly, generation, citation, and response validation. The discipline that separates working RAG from theatre — chunk-size experimentation, retrieval recall measurement, hybrid retrieval, query rewriting for vague questions, and citation-aware generation. Build a production-style RAG service with measured retrieval quality.

A first RAG build almost always works on the demo question and fails on the real ones. This module is the repair kit. You measure before you change anything: retrieval recall and precision at k on a golden question set, so you can tell a retrieval failure from a generation failure — the single most common misdiagnosis in production RAG, and the reason teams spend weeks tuning a prompt when the right chunk was never retrieved.

From there: query decomposition for multi-part questions, hypothetical-document embedding, metadata filtering and structured pre-filters, parent-document and sentence-window retrieval, cross-encoder re-ranking, and context compression to fit more signal into the same budget. Grounding gets its own treatment — enforcing that every claim traces to a retrieved passage, and detecting the answer that sounds supported but is not. You close with RAG-specific evaluation: faithfulness, answer relevance, context precision and context recall, run as a repeatable suite rather than a one-off check.

Agentic workflows — LLMs that call tools, query databases, hit APIs, and loop until a goal is satisfied. Cover OpenAI function calling, Claude tool use, Anthropic's Model Context Protocol (MCP) for tool federation, the agent design loop (think → act → observe → think), task decomposition patterns, ReAct, error handling, and the honest limits of agents in production today (cost, latency, debuggability). Build a multi-tool agent that combines retrieval, computation, and external APIs against a real-world workflow.

Frameworks are tools, not religion. Cover the working subset of LangChain (chains, runnables, LangGraph for state machines), LlamaIndex (best-in-class for RAG over heterogeneous data), and Pydantic-AI (type-safe agent design — the framework Pune Python teams have been gravitating to in 2026). Honest comparison with hand-rolled stacks — when frameworks save time, when they obscure debugging, and when senior AI Engineers reach for vanilla SDK calls instead. Build the same small project in two of the three frameworks to feel the difference.

The week that separates senior AI Engineers from prompt-tinkerers. Cover offline evaluation — RAGAS for RAG quality (faithfulness, answer relevance, context precision / recall), DeepEval for unit-test-style LLM evaluation, human-in-the-loop evaluation patterns. Online observability — Langfuse / LangSmith for tracing, latency / cost / token tracking, structured logging that an SRE can actually debug. Guardrails — content filtering, prompt injection defence, jailbreak resistance, output safety, and the discipline of red-teaming your own system before shipping.

Security and responsibility treated as engineering requirements rather than a closing slide. Prompt injection is the defining vulnerability class of LLM applications: untrusted text — a retrieved document, a user upload, a web page an agent fetched — carrying instructions the model then follows. You work through direct and indirect injection, why input filtering alone does not fix it, and the defences that do hold: separating instructions from data, constraining tool permissions, validating output before it acts, and requiring human approval before anything irreversible.

Alongside that: PII detection and redaction before text reaches a third-party API, data-retention and residency questions that decide whether a Pune BFSI or healthcare client can use a hosted model at all, bias and fairness in generated content, output moderation, and audit logging that records what was asked and what was returned without becoming a new leak. The module is framed against the OWASP Top 10 for LLM Applications, which is the checklist enterprise security reviews actually use.

When and why to leave the frontier APIs. Cover the open-source landscape (Llama 3.x, Mistral, Phi-3, Qwen, IndicBERT for Indian languages), local serving (Ollama for dev, vLLM / TGI for production, llama.cpp for CPU / Apple Silicon), parameter-efficient fine-tuning (LoRA, QLoRA, PEFT) on a single consumer GPU or Colab Pro, dataset preparation for fine-tuning, training discipline (overfitting checks, evaluation), and the honest comparison — when fine-tuning a small open model beats prompting a frontier model (privacy, cost, latency, domain register) and when it doesn't.

Beyond text. Vision-language models (Claude vision, GPT-4-vision, Gemini multimodal) for document understanding, OCR, and visual QA. Image generation (DALL-E 3, Imagen, Stable Diffusion 3, Flux) and the production patterns (asset pipelines, brand-safe filtering, costs). Speech (Whisper for transcription, ElevenLabs for synthesis), code generation (Claude / GPT for code, the honest 'pair programmer' pattern), and the multimodal RAG pattern (text + image retrieval). Plus a cost-conscious approach since multimodal calls run 5–10× the cost of text-only.

An LLM feature that works but costs more than it earns gets switched off, and the engineer who cannot explain the bill does not get to defend it. This module makes cost a design input rather than a monthly surprise. You learn to read a pricing page properly — input against output tokens, cached input, and why a long system prompt repeated on every call is usually the largest line item — and to estimate cost per request before writing the feature.

Then the levers, in the order they pay off: choosing the smallest model that passes your evaluation rather than the best one available, routing easy requests to a cheap model and hard ones to a strong model, exact and semantic caching, prompt compression, trimming retrieved context, batching, and streaming to improve perceived latency without changing spend. You also cover rate limits, quota planning and fallback chains, then build a small cost dashboard so the number is visible to the team rather than discovered on the invoice.

The week that turns a notebook into a service. FastAPI as the de facto serving layer for GenAI in Python (async endpoints, Pydantic v2, JWT auth, streaming responses with Server-Sent Events, WebSocket for chat). Docker for containerisation, GitHub Actions CI/CD with model-call mocking in tests, observability (Langfuse + Prometheus + Grafana for production-grade GenAI telemetry), and FinOps for LLM calls — token budgets per request, caching (semantic cache + exact cache), prompt compression, and the patterns that cut a runaway OpenAI / Anthropic bill by 50–70% without changing model quality.

Two weeks of full-time capstone work plus structured interview preparation. Pick one of three capstone projects (see Capstone Projects). Mock interviews calibrated for Pune AI Engineer hiring panels — Persistent, BMC, Bajaj Finserv, Tiger Analytics, Fractal, BMW TechWorks, Mercedes-Benz R&D, TCS Research, Infosys Topaz, Mastercard Pune Tech Hub. Includes a system-design round (design a customer-support assistant for a BFSI company), an evaluation round (how would you measure if this RAG is working?), and a behavioural / product-thinking round. Resume / LinkedIn / GitHub polish included.