ChatGPT & LLMs Training in Pune with Placement

The course opens with the mental model every later module depends on: what a Large Language Model is, what it can do reliably, and where it fails. You learn the OpenAI model family in practical terms — GPT-5 and GPT-4.1 for reasoning and general application work, smaller models for low-cost throughput, embedding models for retrieval, Whisper for speech, and multimodal models for images and documents.

The setup work is deliberately hands-on. Students configure API keys, install the Python and TypeScript SDKs, use the Playground for fast experiments, and build a first chat-completion call that logs request, response, token usage and cost. By the end of the week you can explain the difference between a chat UI and an LLM API, and you have a working local environment ready for the rest of the course.

Once the environment works, the API surface becomes the subject. You study system, user and assistant messages, when to keep state in your application instead of assuming the model remembers, how temperature and token limits affect output, and why prompt templates should live in code rather than in someone’s notes app.

The module then moves from a blocking response to a production-style streamed response. Students wire Server-Sent Events into a small chat endpoint, add graceful timeout handling, and compare the user experience of streaming with a plain request-response flow. The goal is not only to make a chat box, but to understand the request lifecycle of an LLM feature.

The third week turns natural-language output into software you can trust. You learn Structured Outputs with JSON Schema, schema-constrained generation, Pydantic validation, retry-and-repair loops, and the difference between asking a model to 'return JSON' and requiring a shape your application can parse.

Hands-on labs focus on practical extraction: pulling fields from resumes, invoices, support tickets and product documents; validating the output; and writing tests that catch schema drift. This is the point where students begin thinking like application engineers rather than prompt users, because every response must either pass a contract or fail safely.

Function calling is where an LLM stops being a text generator and starts becoming part of a workflow. You define tools with JSON schemas, let the model choose when to call them, execute those tools in your code, and return observations to the model for the next step.

The engineering discipline gets equal weight: tool arguments must be validated, database access must be parameterised, external API calls need retries, and dangerous actions need approval gates. Students build a small assistant that combines a calculator, a database lookup and a REST API call, then intentionally break it to learn how tool misuse appears in logs.

This week teaches the most common enterprise LLM pattern: grounding a model in documents instead of hoping it already knows the answer. You learn embeddings, vector similarity, chunking, metadata, retrieval quality and the difference between semantic search and keyword search.

The implementation uses both managed and self-hosted paths. Students build one RAG prototype with OpenAI Vector Stores and File Search, then compare it with a simple pgvector or Chroma implementation so they understand what the managed layer hides. The module closes with citation-aware answers and a small evaluation sheet that records whether the right chunks were retrieved.

After the raw APIs, students study the productised OpenAI surfaces and learn when each belongs in a real organisation. Custom GPTs are treated as the fast internal-tool path for business users. The Assistants API is treated as the developer path for stateful applications with tools, files and longer-running work. The Realtime API introduces voice and low-latency interaction patterns.

The practical output is a decision matrix: when to use a Custom GPT, when to build on Assistants, when to stay with raw chat completions, and when the complexity is not justified. Students build a small assistant with files, tools and conversation state, then compare the trade-offs against the earlier FastAPI implementation.

Fine-tuning is taught as a choice, not as a badge. You learn when it helps — domain tone, repeated classification, extraction style, cost reduction — and when RAG or better prompting is the correct answer. The module covers dataset preparation, train / validation splits, examples in the required format, post-fine-tune evaluation and rollback planning.

The second half is production engineering: serving through FastAPI, logging prompts safely, tracing calls with Langfuse or OpenAI usage dashboards, using the Batch API for non-real-time workloads, and applying moderation or safety checks where user-generated content is involved. The emphasis is that a model feature is a service with operations, cost and failure modes.

The final teaching week converts the course into a portfolio artefact. Students choose a capstone, implement it with a clean repository, add a README, record setup steps, capture screenshots or a demo video, and write an evaluation note that explains quality, latency, cost and known limits.

Interview preparation runs beside the capstone rather than after it. You practise explaining OpenAI API choices, tool schemas, RAG retrieval failures, streaming architecture and fine-tuning trade-offs. The aim is simple: when an interviewer opens your GitHub project, you can walk through not just what it does, but why each engineering choice was made.