Abstract mark of six nodes joined by lines, shaped like a small network TFUG.in

Machine learning notes

Machine learning and AI for developers in India

Notes for engineers getting from “I have heard of neural networks” to something that actually runs.

What a developer community is good for, the order in which the fundamentals stick, how the main libraries differ, and how to build a project that survives being read by somebody else.

Diagram of a feed-forward neural network: an input layer of four nodes, two hidden layers, and a two-node output layer, joined by weighted connections

01 / Why a group

What an ML community is actually for

Learning machine learning alone fails in a specific way: the tutorial works, your own data does not, and nobody can tell you whether the thing blocking you is a bug or the nature of the problem. A room that mixes students, engineers moving sideways into ML and full-time practitioners fixes that cheaply.

  • CalibrationHow long training takes, how often experiments fail, how much of the work is cleaning data rather than modelling. The normal numbers are reassuring.
  • Problems you would never meetSomebody is always working on a domain you have not touched: speech in Indian languages, crop imagery, fraud scoring, handwritten forms. Those constraints teach more than a toy set.
  • A deadline you acceptHalf-finished side projects get finished the week before somebody has to look at them.

02 / Getting started

A realistic path in, in the order that works

The common mistake is starting with theory and quitting before anything runs. Reverse it.

  1. Python and arrays first. Indexing, broadcasting, shapes. Most beginner ML bugs are shape errors in a costume.
  2. One model, end to end, badly. Load a small dataset, train, measure, save, load it back, predict one new example. Every later project hangs on that skeleton.
  3. Learn to read failures. Loss going to NaN, loss that will not move, training accuracy perfect and test accuracy useless: each has a short list of usual causes. Recognising them is the skill.
  4. Rebuild a known result. Pick something with a published number and get close. If you cannot, you have found the leak in your pipeline.
  5. Then the maths. Once you have watched gradient descent misbehave, derivatives and probability stop being abstract.

Expect months, not weekends.

Five numbered milestones rising along a dashed line, from Python and arrays up to shipping something small
Four stacked layers of a machine learning framework: array math on CPU and GPU, automatic differentiation, layers and optimisers, and a high-level model API

03 / Libraries

The toolkit, and what really differs

Every deep learning framework does the same core job: hold arrays, run them on a GPU, compute gradients automatically. What differs is where the seam sits.

  • scikit-learnClassical models on the CPU: regression, trees, boosting, clustering. For a tabular problem, usually the right answer.
  • PyTorchThe network is ordinary Python that runs line by line, so a breakpoint still works. Most new research code ships in it.
  • TensorFlowBuilds a graph of the computation, which makes running a model outside Python straightforward: a server, a phone, a browser. Keras rides on top.
  • JAXArray operations plus function transforms: differentiate, vectorise, compile. Strict about functional style, favoured where you want control over the maths.

Choose by what has to happen to the model afterwards. And on tabular data, gradient boosting still often beats a neural network.

04 / Meetups

How developer meetups are usually run

Four panels showing meetup formats: a slide and rows of listeners, a keyboard grid with a cursor, a diff with added and removed lines, and a clock above branching paths

Four formats cover most of what happens in technical groups.

  • The talkTwenty to forty minutes, one idea, slides. Good for surveying a topic, weak for teaching a skill: nobody learns to code by watching.
  • The hands-on workshopEveryone follows along on their own laptop. The hard part is the environment: ship a notebook or container so the first forty minutes are not lost to installing things.
  • The code or paper readingA group works through one repository or paper out loud, line by line. The most underrated format: you see how experienced people read unfamiliar code.
  • The hackathon or build sessionA fixed block of hours, a rough goal, small teams. Bad code, good learning. The value is the constraint, not the prize.

If you are organising, the binding constraint is the room: sockets, a readable screen, and a network that survives thirty laptops pulling one dataset.

05 / Speaking

Preparing a first technical talk

You do not have to be an expert. The strongest beginner talk is “here is what I tried, what went wrong, and what I would do differently” — more useful than a survey of a field you read about last week.

  1. Open with the problem and a number. “Sorting forty thousand tickets by hand took two people a week” beats a definition slide.
  2. Show the naive attempt and why it failed. That is the part the audience remembers.
  3. Show what you changed. One chart, labelled axes, baseline named.
  4. End on what you still do not know. It invites questions instead of silence.

Mechanics matter more than people expect. Rehearse against a timer and cut to eighty per cent of your slot, because you speak slower on the day. Six lines of code on a slide, never a whole file. And screenshot every live demo, because live demos fail.

06 / Building

A learning project worth showing

Training pipeline as connected stages: raw data, split, features, train, evaluate and ship, with a dashed loop back from evaluate to train

A portfolio project is evidence you can take something ambiguous and make it work.

  • A question someone could disagree withPredicting one thing from another is a project; exploring a teaching dataset is homework.
  • An honest baselineCompare against the dumbest thing that works: predict the majority class, or yesterday’s value. A model that does not beat that is not yet a model.
  • A split you can defendRandom splits on time series leak the future into the past; splitting one user across train and test leaks identity. Say how you split, and why.
  • Failure analysisLook at what the model got wrong and describe the pattern. It separates people who trained a model from people who understand one.
  • A README that runsExact commands, a pinned environment, an expected number at the end. If a stranger reproduces it, they believe the rest.

Scope it small: one dataset, one question, one metric, finished.

07 / Data

Where to get data to practise on

Open data is plentiful; the hard part is picking one that teaches you something.

  • Dataset hubs and competition archivesLarge, documented, often already split, with published scores to measure yourself against.
  • Government and civic open data portalsCensus, transport, weather, agriculture, public health. Messy and real: mixed encodings, merged header rows, district names spelled four ways. The mess is the lesson.
  • Research benchmark collectionsImage, speech and text corpora released alongside papers. Read the licence before using one beyond study.
  • Your own logsAnything you run that writes a timestamped record is a dataset nobody else has.

Record where a set came from and which version. And before modelling, spend an hour reading rows: duplicates, impossible values and a column that is quietly a copy of the answer are found by looking, not by training.

Abstract data table of rows and columns with feature and label columns tinted differently, above a bar split into train, validation and test portions