Private corporate batches, live online cohorts and 1-on-1 mentoring in text as data — preprocessing, embeddings, transformers, fine-tuning, retrieval-augmented generation and NLP systems in production — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Natural Language Processing as an engineering discipline built on a stack of representations: what tokenisation and normalisation do to a corpus, why TF-IDF and a linear classifier remain the right answer for a large class of problems, how embeddings turn semantic similarity into geometry, and what self-attention actually computes inside a transformer. Sessions work hands-on through the whole path — spaCy and NLTK pipelines, classical models and their evaluation, embeddings and vector search, fine-tuning pretrained encoders with Hugging Face, then large language models in practice with prompting, retrieval-augmented generation over a real document set, and structured output extraction. The production half is treated as first-class: building an evaluation set that measures the task rather than flattering the model, cost and latency budgeting, hallucination and guardrails, handling personal data in text, monitoring for drift, and choosing deliberately between a small fine-tuned model and a large hosted one.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Natural Language Processing that means a trainer who has run it in production — text as data — preprocessing, embeddings, transformers, fine-tuning, retrieval-augmented generation and NLP systems in production — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Natural Language Processing batchNatural Language Processing is the field concerned with getting computers to work usefully with human language — classifying it, extracting structure from it, searching it by meaning, translating it, summarising it and generating it. It sits between computational linguistics, machine learning and software engineering, and its defining difficulty is that language is ambiguous, context-dependent, endlessly varied and full of things a model has never seen.
The field has been rebuilt roughly three times. The first generation was rules and statistics over word counts: tokenisation, stemming, bag-of-words and TF-IDF vectors feeding classifiers such as naive Bayes, logistic regression or conditional random fields. Those methods are still the correct answer for many production problems, because they are fast, interpretable and cheap. The second generation introduced dense embeddings — word2vec, GloVe, fastText — which represented words as vectors positioned by the company they keep, so that semantic similarity became a geometric measurement. The third and current generation is the transformer: self-attention over a whole sequence, models pretrained on enormous corpora, then either fine-tuned for a specific task or prompted directly.
That third generation is why Natural Language Processing changed from a specialist research area into ordinary engineering work. A pretrained encoder such as BERT can be fine-tuned for classification or entity recognition with a modest labelled dataset. A large generative model can be prompted for summarisation, extraction or dialogue with no training at all, and grounded in your own documents through retrieval-augmented generation over a vector index. The engineering problems have moved accordingly — evaluation, latency, cost per token, hallucination, prompt and context management, data governance and drift are now the difficult parts, rather than the modelling itself.
Most of the data an organisation holds is text: support tickets, contracts, clinical notes, chat transcripts, product reviews, incident write-ups, regulatory filings and email. Until recently that data was practically inert — searchable by keyword at best, and otherwise processed by people. It is now tractable, and every function that handles text volume at scale has a reason to automate part of it.
What changed is accessibility rather than possibility. Pretrained models removed the requirement for a large labelled corpus and a research team. An engineer with a solid Python background can now fine-tune a classifier in an afternoon or stand up a retrieval-augmented assistant over an internal document set in a week. That has created demand for a specific profile: not a research scientist, but an engineer who understands what these models do, where they fail, and how to evaluate them honestly.
The honest evaluation part is where organisations are struggling most. Demonstrations are easy and production systems are not. Knowing when a TF-IDF classifier beats a language model on cost and accuracy, how to build an evaluation set that actually measures the task, how to detect and reduce hallucination, how to control latency and cost per request, and how to handle personal data in text are the skills that separate a prototype from something a business can rely on.
What makes language hard for machines, and the task taxonomy that turns a vague request into something you can measure. Ambiguity at every level, the standard task types, the three generations of approach and where each still applies, and the framing work that decides whether a project succeeds before any model is chosen.
Topics: Why language is hard: lexical, syntactic, semantic and pragmatic ambiguity · The task taxonomy: classification, extraction, retrieval, generation, translation, summarisation · Rules, statistics, embeddings, transformers: three generations and what survived · Framing a business request as a measurable NLP task · Baselines, and why you always need a stupid one · Data requirements and labelling reality · Where NLP is the wrong tool · Python, notebooks and the working environment · The library landscape: NLTK, spaCy, scikit-learn, Hugging Face, PyTorch
Getting from raw text to something a model can consume, and understanding what each step destroys. Encoding and cleaning, tokenisation strategies including subword tokenisers, normalisation choices with their consequences, then the linguistic layer — part-of-speech tagging, lemmatisation, dependency parsing and named entity recognition — worked through spaCy pipelines.
Topics: Text acquisition, encoding, and cleaning HTML, PDF and scanned sources · Sentence segmentation and its failure cases · Tokenisation: whitespace, rule-based, and subword tokenisers · Normalisation: casing, accents, punctuation, numbers · Stopwords, stemming and lemmatisation, and what each costs · Part-of-speech tagging · Dependency parsing and syntactic structure · Named entity recognition with pretrained models · Rule-based matching and the Matcher API · Building and customising a spaCy pipeline · Handling multilingual and code-mixed text · Regular expressions, and their limits
The methods that remain the right answer more often than the hype suggests. Bag of words, n-grams and TF-IDF; vector space similarity; classifiers — naive Bayes, logistic regression, linear support vector machines — and sequence models; then evaluation done properly, with the class imbalance and leakage problems that make most first results wrong.
Topics: Bag of words, n-grams and count vectorisation · TF-IDF weighting and why it works · Cosine similarity and the vector space model · Naive Bayes for text classification · Logistic regression and linear support vector machines · Feature engineering for text · Sequence labelling and conditional random fields · Topic modelling: LDA and NMF · Train, validation and test splits, and preventing leakage · Precision, recall, F1, macro versus micro averaging · Class imbalance and threshold selection · Cross-validation and confidence in a result · Interpreting a linear model's coefficients
Representing meaning as geometry. The distributional hypothesis; word2vec, GloVe and fastText and how they differ; why static word embeddings cannot handle polysemy; sentence and document embeddings; similarity, clustering and analogy; then vector databases, indexing methods and the practical work of building semantic search over a real corpus.
Topics: The distributional hypothesis · word2vec: skip-gram and continuous bag of words · GloVe and fastText, and subword information · Training your own embeddings versus using pretrained ones · Limits of static embeddings: polysemy and context · Sentence embeddings and sentence-transformers · Similarity, clustering and visualisation with UMAP or t-SNE · Bias encoded in embeddings, and how to measure it · Vector databases and approximate nearest neighbour indexes · Chunking strategy for documents · Hybrid search: combining lexical and semantic retrieval · Evaluating retrieval quality: recall at k, mean reciprocal rank, NDCG
The architecture behind everything current. Attention and self-attention explained so the behaviour is predictable rather than mysterious; encoder, decoder and encoder-decoder models and what each is for; tokenisers and context windows; the pretraining and fine-tuning paradigm; then the Hugging Face ecosystem and fine-tuning a model for a real task with a measured gain over the baseline.
Topics: Attention and self-attention, worked through by hand · The transformer block: multi-head attention, feed-forward, residuals, normalisation · Positional encoding · Encoder models, decoder models and encoder-decoder models · BERT and the masked language modelling objective · Subword tokenisers: byte-pair encoding, WordPiece, SentencePiece · Context windows, truncation and long-document strategies · Pretraining, fine-tuning and transfer learning · The Hugging Face ecosystem: models, datasets, tokenizers, trainer · Fine-tuning for classification and token classification · Parameter-efficient fine-tuning: LoRA and adapters · Distillation, quantisation and smaller models · Reading a model card and choosing a model responsibly
The tasks organisations actually ask for, each built and evaluated. Document and intent classification; entity extraction including custom entity types; sentiment and aspect-based sentiment with its well-known pitfalls; summarisation, extractive and abstractive; question answering; translation; and the document processing pipelines that combine several of these.
Topics: Document, intent and multi-label classification · Named entity recognition for custom entity types · Relation extraction and structured output from text · Sentiment and aspect-based sentiment analysis · Sarcasm, negation and domain shift in sentiment · Extractive versus abstractive summarisation · Extractive and generative question answering · Machine translation and quality estimation · Text similarity, deduplication and clustering · Keyword and keyphrase extraction · Document processing pipelines combining tasks · Task-appropriate metrics: ROUGE, BLEU, exact match, F1 and their limits
Using generative models as components in a system rather than as a chat window. Prompting techniques and their reliability; structured output and schema enforcement; retrieval-augmented generation from chunking through retrieval to grounded answering; tool use and agentic patterns; hallucination, guardrails and evaluation; and the cost, latency and model-selection decisions.
Topics: How generative models produce text, and what sampling parameters do · Prompt design: instructions, examples, roles and delimiters · Few-shot prompting and chain-of-thought style reasoning · Structured output: JSON schemas, function calling and validation · Retrieval-augmented generation architecture end to end · Chunking, embedding, retrieval and reranking · Grounding, citation and refusing to answer · Context window management and cost per request · Tool use and multi-step agentic patterns · Hallucination: causes, detection and mitigation · Guardrails, prompt injection and input sanitisation · Evaluating generative output: rubrics, model-as-judge and human review · Choosing between a hosted model, an open-weight model and a fine-tuned small model
Everything between a working notebook and a system a business depends on. Serving and scaling, batching and caching, latency and cost budgets; data pipelines and versioning; monitoring, drift and feedback loops; the privacy question that text data always raises; fairness and bias review; and the human-in-the-loop design that most real deployments need.
Topics: Serving models: API design, batching, caching and GPU versus CPU · Latency budgets and where time actually goes · Cost modelling per request and per user · Data pipelines, dataset versioning and reproducibility · Experiment tracking and model registries · Monitoring: input drift, output drift and quality regression · Building a feedback loop and a labelling workflow · Human-in-the-loop and confidence thresholds · Personal data in text: detection, redaction and retention · Regulatory considerations for automated text decisions · Bias, fairness and representational harm in language systems · Model updates, shadow deployment and rollback · Documentation: model cards and system cards
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a preprocessing pipeline over a genuinely messy corpus, then demonstrate three cases where an ordinary normalisation step removes exactly the signal the task depends on.
Build a TF-IDF classifier, evaluate it honestly, find and remove a data leak, then keep it as the baseline every later model has to beat on accuracy, latency and cost.
Build semantic search over a real document set with embeddings and a vector index, then compare it against keyword search on the same query set with recall and NDCG.
Fine-tune a pretrained transformer for a real classification or extraction task and compare it against the classical baseline on accuracy, latency, cost and error profile.
Build retrieval-augmented generation end to end — chunking, retrieval, reranking, grounded answering with citations — then measure how often it answers from the documents rather than from itself.
Take one NLP application to deployment: API, latency and cost budget, evaluation suite, drift monitoring, privacy handling and a written model card.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.