Speaker 1: The world of AI and machine learning is just exploding,
Speaker 1: isn't it. And if you're a coder looking in, you
Speaker 1: might be thinking, Okay, how do I actually get started
Speaker 1: here without needing a PhD.
Speaker 2: That's a really common question and honestly, the tools available
Speaker 2: now have made it much more accessible for developers to jump.
Speaker 1: In absolutely, and that's really our mission for this deep dive.
Speaker 1: We're digging into key parts of Lawrence Moroney's book AI
Speaker 1: and Machine Learning for coders. We want to pull out
Speaker 1: the most important bits for you.
Speaker 2: Think of it as a practical starting point. We're aiming
Speaker 2: to give you the essentials on deep learning, computer vision,
Speaker 2: and LP, basically focusing on how you can use TensorFlow
Speaker 2: to tackle these things.
Speaker 1: Yeah, the perspective here is crucial. It's tailored for you,
Speaker 1: the coder. It's about the tools you can grab now
Speaker 1: and the problems you can start solving.
Speaker 2: Right, just like the book intents equipping you to become
Speaker 2: an mL developer by focusing on actually doing it, not
Speaker 2: getting bogged down in just the theory or the super
Speaker 2: complex math.
Speaker 1: And people have really responded to that approachmon called it
Speaker 1: the much needed practical starting point. Soufu mentioned how it
Speaker 1: teaches the key building blocks so you can code AI
Speaker 1: for PCs mobile the browser.
Speaker 2: Yeah, Laurence Maroney's vision was clearly about empowering developers, and,
Speaker 2: like Andrew En says in the foreword, great Adventures await you,
Speaker 2: it's an exciting space.
Speaker 1: Okay, So let's unpack this. Where does machine learning really
Speaker 1: differ from say, traditional programming and what's the main platform.
Speaker 3: We'll be talking about.
Speaker 2: Well, the fundamental difference is a kind of flip in thinking.
Speaker 2: In traditional programming, you write explicit rules, rules, act on data,
Speaker 2: and you get answers.
Speaker 1: Like coding a game like Breakout, specifically, write the logic
Speaker 1: how the ball moves, what happens when it hits a brick, scoring, paddle, misses.
Speaker 1: It's all defined rules exactly.
Speaker 2: Or think about activity detection from a wearable. You might
Speaker 2: write rules like okay, if speed is over x, it's running.
Speaker 2: If it's between y and X, it's walking. You define
Speaker 2: the logic based on the data.
Speaker 1: But that approach hits the ceiling pretty quickly, right. What
Speaker 1: if you wanted to detect something way more complex, like
Speaker 1: golfing precisely?
Speaker 2: How do you write rules for that? The mix of
Speaker 2: swinging pausing walking, It gets incredibly hard, maybe even impossible,
Speaker 2: to define robust rules that cover every single variation by hand.
Speaker 1: So the old rules act on data to give answers.
Speaker 1: Method breaks down and the rules are just too fuzzy
Speaker 1: or complex to write yourself. And that's where mL comes in.
Speaker 2: Right. With machine learning, you kind of flip it. You
Speaker 2: provide the data and you provide the answers. We call
Speaker 2: those labels. Then the machine learning algorithm figures out the
Speaker 2: rules or patterns connecting the data to those answers.
Speaker 3: Ah okay.
Speaker 1: So for the activity example, you'd give it sensor data
Speaker 1: from someone walking, running, biking, and golfing, and you'd label
Speaker 1: those chunks of data this part is walking, this part
Speaker 1: is golfing.
Speaker 2: Yep. And the mL algorithm looks at all that labeled
Speaker 2: sensor data maybe acceleration, rotation time, whatever, and it learns
Speaker 2: the underlying patterns that distinguish golfing from the others. It
Speaker 2: derives the complex rules you couldn't realistically right, that's the
Speaker 2: core shift. It's pretty powerful, and.
Speaker 1: The platform that's really designed to put this power into
Speaker 1: coder's hands is TensorFlow.
Speaker 2: TensorFlow, Yeah, it's this huge open source platform for building
Speaker 2: and using mL models. Its real value, I think is
Speaker 2: that it handles a lot of the underlying complexity. It
Speaker 2: implements common algorithms, common patterns, so you.
Speaker 1: The coder can focus more on the actual problem you're
Speaker 1: trying to solve with mL, unless on say, implementing backpropagation from.
Speaker 2: Scratch, exactly focus on the scenario. And TensorFlow is built
Speaker 2: to be flexible. You can deploy the models you create
Speaker 2: almost anywhere web cloud, mobile apps, on Android or iOS,
Speaker 2: even tiny embedded systems.
Speaker 1: And how do you typically work with it? Python, install idse.
Speaker 2: All of the above. Really, you can pip install it
Speaker 2: in Python, use it in IDEs like pischarm, or a
Speaker 2: really popular way is using cloud environments like Google Collab
Speaker 2: that gives you access to GPUs and TPUs without needing
Speaker 2: the hardware yourself.
Speaker 1: Okay, let's drill down. What does the simplest possible example
Speaker 1: of this learning look like? Like the basic building.
Speaker 2: Block, right, So imagine teaching a network a really simple
Speaker 2: linear relationship like why equals two x one? You'd give
Speaker 2: examples if x is one, why is one of x's two,
Speaker 2: Why is three x's three, y is five? And so
Speaker 2: on Okay, a tiny neural network, even one with just
Speaker 2: a single neuron, can learn this. It does it by
Speaker 2: adjusting two internal values, a weight it multiplies the input
Speaker 2: x by, and a bias it adds.
Speaker 1: So it's basically learning the two in the menx one
Speaker 1: from our equation. Yeah, those learned numbers, the weight and bias,
Speaker 1: those are the parameters.
Speaker 2: Of the network exactly, And that's a really important distinction
Speaker 2: for coders getting into mL. Parameters, weights and biases are
Speaker 2: what the network learns from the data. They're different from hyper.
Speaker 1: Parameters, right. Hyperarameters are the knobs you turn before training starts.
Speaker 1: Aren't they things that control the learning process itself.
Speaker 2: Yeah, things like the learning rate, how quickly it adjusts weights,
Speaker 2: or the number of neurons you decide to put in
Speaker 2: a layer, or how many epochs meaning how many times
Speaker 2: it sees a whole data set. You experiment with these
Speaker 2: to get better results. And neurons also usually have something
Speaker 2: called an activation function. It's like a little function that
Speaker 2: processes the neurons output. A common one is relute rectified
Speaker 2: linear unit. It basically just passes the value through if
Speaker 2: it's positive and outputs zero otherwise. This adds nonlinearity, which
Speaker 2: is crucial for learning anything beyond simple lines.
Speaker 1: Okay, makes sense. We've got the basic shift to learning
Speaker 1: the platform, the simplest building block. Let's apply this to
Speaker 1: a huge area. Yeah, computer vision making machines.
Speaker 2: See so at its core and image is just a
Speaker 2: grid of numbers, right pixels. A small gray scale image
Speaker 2: like from the Fashion MNIS data set might be twenty
Speaker 2: eight by twenty eight pixels. Each pixel has a value,
Speaker 2: say zero to two fifty five for how bright it.
Speaker 1: Is, and color images just have more numbers per pixel,
Speaker 1: usually three for red, green, and blue.
Speaker 2: Three channels.
Speaker 3: Yeah.
Speaker 2: Now if you try to feed those raw pixel values
Speaker 2: directly into that simple single neural network we just talked about,
Speaker 2: or even a basic multi layer network, well it would
Speaker 2: really struggle because a simple network doesn't understand spatial structure.
Speaker 2: It just sees a flat list of numbers. It might
Speaker 2: learn to recognize, say a sneaker, if it's exactly like
Speaker 2: the ones in the training data, same position, same angle.
Speaker 1: Ah, but if you show it the sneaker slightly rotated,
Speaker 1: or maybe a different type of sneaker, like a high heel, it.
Speaker 2: Might completely fail. It hasn't learned the features that make
Speaker 2: something a sneaker. It just memorized specific pixel patterns in
Speaker 2: specific locations.
Speaker 3: Okay, so that's the problem.
Speaker 1: Convolutional neural networks or CNNs are designed.
Speaker 2: To solve exactly. CNNs are built to automatically find and
Speaker 2: learn hierarchical features in images, things like edges, textures, shapes, objects,
Speaker 2: regardless of where they appear in the image.
Speaker 3: How do they do that? What are the core ideas?
Speaker 2: Two main operations, convolutions and pooling. Convolutions use small filters,
Speaker 2: like maybe a three by three grade of weights that
Speaker 2: slide across the image. Each filter is trained to detect
Speaker 2: a specific local pattern, maybe a vertical edge or a
Speaker 2: certain curve or text.
Speaker 1: So the filter scans the image and produces a sort
Speaker 1: of map showing where it found that.
Speaker 2: Pattern precisely, and applying a filter reduces the image dimensions slightly.
Speaker 2: A three x three filter on a twenty eight x
Speaker 2: twenty eight image gives you a twenty six x twenty
Speaker 2: six output map.
Speaker 3: Okay, and pooling.
Speaker 2: Pooling layers then reduce the size of these feature maps,
Speaker 2: making the representation smaller and more manageable while keeping the
Speaker 2: most important information. A common type is max pooling. You
Speaker 2: might take a two x two area and just keep
Speaker 2: the maximum value, throwing away the other three. This halves
Speaker 2: the dimensions but keeps the strongest signal for that feature
Speaker 2: in that region.
Speaker 1: And by stacking these convolutions and pooling layers.
Speaker 2: The network builds up understanding. Early layers find simple edges,
Speaker 2: Middle layers combined edges into corners and textures. Deeper layers
Speaker 2: combine those into parts of objects, and then whole objects.
Speaker 2: The key thing for you as a coder is that
Speaker 2: the CNN automates this feature extraction. You don't have to
Speaker 2: hand code edge detectors anymore.
Speaker 3: Right, Let's make it concrete.
Speaker 1: The book uses a horse or human classifier.
Speaker 3: Example.
Speaker 2: Yeah, that data set uses bigger color images, maybe three
Speaker 2: hundred by three hundred pixels with three color channels. So
Speaker 2: the input shape is three hundred by three hundred by three.
Speaker 1: And since it's just two classes horse or human, it's
Speaker 1: binary classification. You can use just one neuron in the
Speaker 1: final output layer.
Speaker 2: You can, and you typically attach a Sigmoid activation function
Speaker 2: to it. Sigmoid squashes any input value into a range
Speaker 2: between zero and one, perfect for probability. You can interpret
Speaker 2: the output as say, the probability that the image is
Speaker 2: a human.
Speaker 1: The source mentioned a specific failure case, though, where a
Speaker 1: model trained on this data set saw a picture of
Speaker 1: just like the top half of a person and classified
Speaker 1: it as a horse. Why would that happen? It seems
Speaker 1: like a common beginner frustration.
Speaker 2: It often boils down to the training data and overfitting.
Speaker 2: If your training set mostly contains full body pictures of
Speaker 2: humans standing up and maybe horses in profile, the model
Speaker 2: learns those specific views. When it sees something unusual, like
Speaker 2: only the upper body of a person perhaps and oppose
Speaker 2: it hasn't seen, it might lapt onto some features, maybe texture,
Speaker 2: maybe background that it learned we're associated with horses in
Speaker 2: the training data. It hasn't generalized the concept of human
Speaker 2: well enough outside the examples it saw.
Speaker 1: Okay, so this overfitting. Doing great on training data but
Speaker 1: failing on new stuff. How do you fight that, especially
Speaker 1: if you don't have tons of data?
Speaker 2: Several really good techniques. One is image augmentation. It's clever.
Speaker 2: During training, you don't just feed the network your original images.
Speaker 2: You apply random transformations on the fly, maybe rotate the
Speaker 2: image slightly, zoom in or out a bit shift. It
Speaker 2: horizontally or vertically flip it.
Speaker 1: Ah, so you're essentially creating slightly modified versions of your
Speaker 1: existing images, making the data set seem bigger and more varied.
Speaker 2: Exactly, the model learns that a horse is still a
Speaker 2: horse even if it's tilted or slightly zoomed, it becomes
Speaker 2: more robust. Tensorflow's image data generator makes this super easy
Speaker 2: to set up.
Speaker 3: What else?
Speaker 2: Another huge one is transfer learning. This is incredibly powerful.
Speaker 2: You might only have a few thousand horse and human images,
Speaker 2: but other people have trained enormous models, like mobile net
Speaker 2: or inception on millions of images covering say one thousand
Speaker 2: different categories on the ImageNet data set. Those massive models
Speaker 2: have already learned really really good general purpose feature extractors
Speaker 2: in their early convolutional layers. They know how to detect edges, textures, shapes,
Speaker 2: basic object parts, things useful for recognizing any image.
Speaker 1: So with transfer learning, you take those pre trained layers.
Speaker 2: Yep, you basically chop off the original final layers that
Speaker 2: were specific to the one thousand image Neet classes. You
Speaker 2: freeze the weights of the early layers so they don't change,
Speaker 2: and you add your own new classification layers on top,
Speaker 2: maybe just a couple of layers ending in that single
Speaker 2: sigmoid neuron for your horse human tasks.
Speaker 1: And you only train your new small layers using your
Speaker 1: smaller data set.
Speaker 2: Mostly yes, or sometimes you fine tune by unfreezing the
Speaker 2: last few pre trained layers and training them a tiny
Speaker 2: bit too. But the point is you're leveraging all the
Speaker 2: knowledge learn from the giant data set for your specific problem.
Speaker 2: It's a massive shortcut. TensorFlow Hub is a great place
Speaker 2: to find these pre trained models.
Speaker 3: That makes a lot of sense any other tricks for overfitting.
Speaker 2: Dropout regularization is another common one. During training, For each
Speaker 2: batch of data, you randomly drop out, meaning temporarily ignore
Speaker 2: a certain percentage of the neurons in a layer.
Speaker 3: Wait, you just turn them off?
Speaker 2: Why It sounds weird, but it forces the network to
Speaker 2: learn more robust and redundant representations. It prevents any single
Speaker 2: neuron from becoming overly specialized or critical for making predictions
Speaker 2: based on the training data. It encourages the network to
Speaker 2: distribute the learning. You often see the training accuracy and
Speaker 2: the validation accuracy performance on data held back from training
Speaker 2: stay much closer together when you use dropout.
Speaker 1: Okay, got it. So that's a good overview for images.
Speaker 1: What about the other big area text, natural language processing?
Speaker 1: How to machine start to understand language?
Speaker 2: Well? Like images, text needs to be converted into numbers first.
Speaker 2: The initial step is usually tokenization.
Speaker 1: Breaking sentences down into words or maybe even parts of words,
Speaker 1: and giving each unique piece a number ID like these
Speaker 1: is one, cat is two, sat.
Speaker 2: As three exactly. You build a vocabulary, a mapping from
Speaker 2: words to integer tokens. Good tokenizers handle things like punctuation.
Speaker 2: Maybe today just becomes the token for today, and crucially,
Speaker 2: you need a plan for words that weren't in your
Speaker 2: training vocabulary and out of vocabulary or OOV token.
Speaker 1: Once you have tokens, you turn sentences into sequences of
Speaker 1: these numbers. The cat sat might become the sequence one
Speaker 1: two three, right.
Speaker 2: And because neural networks usually need fixed size inputs, you
Speaker 2: have to make all your sequences the same length. You
Speaker 2: either pad shorter sequences, usually with zeros, or you trunk
Speaker 2: paate longer ones.
Speaker 3: How do you pick the length?
Speaker 2: You typically look at the distribution of sentence links in
Speaker 2: your data. Maybe ninety five percent of your sentences are
Speaker 2: shorter than say eighty five words, so you might pick
Speaker 2: eighty five as your max length to minimize padding while
Speaker 2: capturing most sentences fully.
Speaker 1: And sometimes you clean the text first, remove HTML maybe
Speaker 1: common words.
Speaker 2: Yeah, preprocessing is often important, removing HTML tags, maybe converting
Speaker 2: to lowercase. Sometimes you remove stop words. Common words like
Speaker 2: is is it is? The that might not carry a
Speaker 2: much specific meaning for your task. So is it sunny
Speaker 2: today might become tokens for just sonny today.
Speaker 1: Okay, so we have sequences of numbers, Yeah, but just
Speaker 1: assigning arbitrary IDs like one, two, three doesn't tell the
Speaker 1: model anything about meaning. Right, Cat two isn't inherently related
Speaker 1: to dog maybe fifty exactly.
Speaker 2: That's where embttings come in. This is a really key
Speaker 2: concept in NLP.
Speaker 3: Right.
Speaker 2: Embeddings represent words not just as single numbers, but as
Speaker 2: vectors lists of numbers in a multi dimensional space. Think
Speaker 2: of it like giving each word coordinates on a complex map, and.
Speaker 1: The idea is that words with similar meanings end up
Speaker 1: closer together.
Speaker 3: On this map.
Speaker 2: Precisely, king and queen might have similar vectors. Walking and
Speaker 2: running might be close. The relationships between words are captured
Speaker 2: by their relative positions in this embedding space.
Speaker 1: The book uses a cool example with pride and prejudice
Speaker 1: characters right, plotting them based on learned dimensions like gender
Speaker 1: or nobility.
Speaker 2: Yeah, that's a great way to visualize it. Mister Darcy
Speaker 2: and Elizabeth Bennett might be positioned based on these learned
Speaker 2: semantic features. The key is that the network learns these
Speaker 2: vector representations. The dimensions aren't predefined. They emerge from how
Speaker 2: words are used together in the training text.
Speaker 1: So the network figures out that king is used in
Speaker 1: similar contexts to queen, but maybe also related to man,
Speaker 1: while queen is related to woman.
Speaker 2: Right, and you can even optimize the number of dimensions
Speaker 2: in your embedding vectors. A rule of thumb is maybe
Speaker 2: the fourth root of your vocabulary size. So for a
Speaker 2: few thousand words, maybe seven or eight dimensions is enough
Speaker 2: instead of say sixteen or three two. It trains faster
Speaker 2: without losing too much meaning.
Speaker 1: But if you'd just average the embedding vectors for all
Speaker 1: words in a sentence, you lose word order, don't you.
Speaker 1: It becomes a bag of words.
Speaker 2: That's a major limitation of simple embedding approaches. Word order
Speaker 2: is critical in language. Dog bites man versus man bites
Speaker 2: dog totally different meanings, same bag of words, So.
Speaker 1: To handle sequence in context, we need something more sophisticated,
Speaker 1: like we're current nural networks RNNs exactly.
Speaker 2: RNNs are designed from the ground up for sequential data.
Speaker 2: They have a kind of internal memory or state that
Speaker 2: gets updated as they process each word or token in
Speaker 2: a sequence. This state carries context from previous words forward.
Speaker 1: But you mentioned simple RNNs can struggle with long sentences.
Speaker 1: They might forget important context from the beginning.
Speaker 2: Yeah, that's the venish ingradient problem. Essentially, the influence of
Speaker 2: early words can fade out over long sequences. If you
Speaker 2: have a sentence like I grew up in France, so
Speaker 2: I speak fluent, the word France early on is key
Speaker 2: to predicting French at the end. A simple RNN might
Speaker 2: lose that connection.
Speaker 1: Okay, and that's why lstm's long short term memory networks
Speaker 1: were developed, right.
Speaker 2: LSTMs are a special type of RNM. They have internal
Speaker 2: mechanisms called gates that expl ilicitly control what information to remember,
Speaker 2: what to forget, and what to output. This makes them
Speaker 2: much much better at capturing long range dependencies and sequences.
Speaker 1: And then there are bidirectional LSTMs. How do they improve things?
Speaker 2: So a standard LSTM reads the sequence from start to end.
Speaker 2: A bidirectional LSTM has two LSTMs. One reads forwards, the
Speaker 2: other reads backwards. Then it combines their outputs at each step.
Speaker 1: Ah, so it gets context from both.
Speaker 2: Directions exactly for understanding language, this is often really powerful.
Speaker 2: Think about sentiment analysis. Sometimes the keyword determining the sentiment
Speaker 2: comes late in the sentence, or for predicting a missing word,
Speaker 2: knowing the words that come after it is just as
Speaker 2: important as knowing the words before it.
Speaker 1: Like that I lived in country right Gaelic example. Seeing
Speaker 1: Gaelic later helps figure out.
Speaker 2: The country precisely. The backward pass provides that future context,
Speaker 2: and you can feed pre trained embeddings like love vectors
Speaker 2: into these LSTMs to give them a head start on
Speaker 2: word meaning.
Speaker 1: Okay, so we can use these models to understand text.
Speaker 1: What about generating text? How does that work?
Speaker 2: The core idea is pretty straightforward. Actually, you train a
Speaker 2: model to predict the next word in a sequence given
Speaker 2: the preceding words.
Speaker 1: So if your training data has the sentence the quick
Speaker 1: brown Fox, you'd create training examples like input the label
Speaker 1: quick input, the quick label brown input, the quick brown
Speaker 1: label Fox exactly.
Speaker 2: You slide a window across your text corpus, creating these
Speaker 2: input sequences and their corresponding next word labels. The labels
Speaker 2: are usually one hot encoded a vector of zeros with
Speaker 2: a single one at the index, corresponding to the correct
Speaker 2: next word in your vocabulary, and the.
Speaker 1: Model architecture would be similar embedding layer than maybe an
Speaker 1: LSTM or bidirectional LSTM.
Speaker 2: Yep, very common. Then to generate text, you start with
Speaker 2: a seed text, maybe a word or a phrase. You
Speaker 2: feed that seed sequence into your trained model. It outputs
Speaker 2: a probability distribution over all the words in your vocabulary
Speaker 2: for what the next word is most likely to be.
Speaker 1: You pick a word based on those probabilities, maybe the
Speaker 1: most likely one.
Speaker 2: Usually yeah, or sometimes you sample from the distribution to
Speaker 2: get more variety. Then you append that predicted word to
Speaker 2: your seed text. Now you have a slightly longer sequence, and.
Speaker 1: You feed that new sequence back into the model to
Speaker 1: predict the next word and repeat.
Speaker 2: That's the loop, keep feeding the growing sequence back in
Speaker 2: predicting the next word, appending it.
Speaker 1: The book had an example using song lyrics right starting
Speaker 1: with in the town of a Lottie yeah.
Speaker 2: And the model correctly predicted one which was the actual
Speaker 2: next word in the song it was trained on, and
Speaker 2: using different seeds like sweet, Jeremy sad Dublin produced other
Speaker 2: plausible next words based on the patterns learned from the lyrics.
Speaker 1: Though it's fair to say these simple generation models can
Speaker 1: often start repeating themselves or outputting stuff that doesn't make
Speaker 1: much sense after a while.
Speaker 2: No, definitely, they can descend into gibberish quite quickly. Getting
Speaker 2: coherent long form text generation is much harder. It often
Speaker 2: involves more complex architectures, maybe stacking multiple LSTM, careful tuning
Speaker 2: of hyper parameters, and more sophisticated sampling strategies. The generated
Speaker 2: Shakespearean text in the book is an example of getting
Speaker 2: something more structured, even if parts are nonsensical, Right.
Speaker 1: Okay, images text? What about data where the sequence is
Speaker 1: time itself, time series data like weather or stock prices.
Speaker 2: Yeah, time series data is everywhere, weather forecasts, stock market trends,
Speaker 2: sensor readings over time, even something like Moore's law tracking
Speaker 2: transistor density. It's all data points ordered chronologically, and this.
Speaker 1: Kind of data often has specific characteristics you need to understand.
Speaker 2: Absolutely. There's often an overall trend is the value generally
Speaker 2: increasing or decreasing over time. There's seasonality patterns that repeat
Speaker 2: at regular intervals, think daily temperature cycles, weekly website traffic spikes,
Speaker 2: yearly retail sales patterns. Okay, there's autocorrelation, meaning the value
Speaker 2: at one point in time is correlated with values at
Speaker 2: previous points, like if it's hot today, it's probably going
Speaker 2: to be warmish tomorrow, or maybe a predictable decay after
Speaker 2: some event, and.
Speaker 1: Then there's always just random noise, right, fluctuations You can't
Speaker 1: really predict exactly.
Speaker 2: Understanding these components helps in modeling.
Speaker 1: So how do you prep time series data for an
Speaker 1: mL model? It's not exactly sentences.
Speaker 2: The standard technique is windowing. You essentially turn the time
Speaker 2: series prediction problem into a supervised learning problem.
Speaker 3: How does that work?
Speaker 2: You create fixed size input sequences or windows of past
Speaker 2: data points. For example, a window might be the last
Speaker 2: thirty days of temperature readings, and the corresponding label for
Speaker 2: that window is typically the value you want to predict,
Speaker 2: maybe the temperature reading for the next day, day thirty one.
Speaker 1: Okay, So you slide this window across your entire time
Speaker 1: series history, creating lots of input window next value pairs precisely.
Speaker 2: That becomes your training data.
Speaker 1: Set, and before you build a fancy mL model, you'd
Speaker 1: probably want some simple baselines to compare against.
Speaker 2: Definitely, you need to know if your MLMA model is
Speaker 2: actually adding value. The simplest baseline is the nive forecast.
Speaker 2: Just predict that the next value will be the same
Speaker 2: as the last observed value, so predict tomorrow's temperature will
Speaker 2: be the same as today's.
Speaker 1: Or maybe a moving average averaging the values in the last.
Speaker 2: Window right that smooths out noise, but often lags behind
Speaker 2: trends and doesn't capture seasonality.
Speaker 3: Well.
Speaker 2: You calculate the error of these baselines maybe mean absolute
Speaker 2: error MAE, and that gives you a target for your
Speaker 2: mL model to beat.
Speaker 1: What mL models work well here on this windowed data You.
Speaker 2: Can try basic dense neural networks DNNs, but architectures that
Speaker 2: understand sequences are often better. You can use one D convolutions,
Speaker 2: similar to how two dcnns find spatial patterns and images.
Speaker 2: One dcnns can find patterns across consecutive timesteps within your window.
Speaker 2: You need to use causal padding, though, to make sure
Speaker 2: the convolution only looks at past data, not future data
Speaker 2: it shouldn't know about.
Speaker 1: Makes sense, and RNNs LSTMs grus absolutely.
Speaker 2: Since time series is inherently sequential, rn n's are a
Speaker 2: natural fit. They can maintain state across the timesteps within
Speaker 2: the window, potentially capturing complex temporal patterns and dependencies that
Speaker 2: simple DNNs or even CNNs might miss.
Speaker 1: So again, it's about experimenting with different window sizes, architectures,
Speaker 1: hyper parameters to see what works best for your specific
Speaker 1: time series.
Speaker 2: Exactly, different data sets will respond better to different approaches.
Speaker 1: Okay, so we've trained all these amazing models for vision
Speaker 1: language time series. Now the crucial part for a coder,
Speaker 1: how do you actually use them in an application deployment?
Speaker 2: Right, if you want to run your model directly on
Speaker 2: a user's device, like in a native mobile app on
Speaker 2: Android or iOS, or maybe on an embedded system like
Speaker 2: a Raspberry Pie, the main tool is tensorflowite.
Speaker 1: T flight And why run it on the device on
Speaker 1: the edge. Why not just call a server API.
Speaker 2: Several big advantages late and see the prediction happens right
Speaker 2: there instantly, no network delay, connectivity, it works even if
Speaker 2: the device is offline, and privacy the user's data like
Speaker 2: an image want to classify, doesn't have to leave their device,
Speaker 2: which is huge nowadays.
Speaker 1: Okay, that makes sense, So how does it work. Let's
Speaker 1: take our simple Y for X one model again.
Speaker 2: So you train your model as usual, probably in Python
Speaker 2: using TensorFlow. You save the trained model. Then you use
Speaker 2: a tool called the TF dot light dot T flight
Speaker 2: converter to convert your saved TensorFlow model into a special
Speaker 2: optimized dot T flight format.
Speaker 3: So you get this lightweight dot T flight file.
Speaker 2: Yep, it's usually much smaller then in your mobile app
Speaker 2: code Jabacotlin for Android, Swift Objective, BAFF for iOS, or
Speaker 2: your embedded system code like Python or C plus plus
Speaker 2: on a PI. You use the t flight interpreter library.
Speaker 2: You load that dot T flight file into the interpreter.
Speaker 2: You prepare your input data, making sure it has the
Speaker 2: exact shape and data type the model expects. For example,
Speaker 2: that might be a float three two array containing ten
Speaker 2: point zero with the shape of one one.
Speaker 3: Gotta get the details right there absolutely.
Speaker 2: Then you pass that input to the interpreter, invoke it,
Speaker 2: run the prediction, and it gives you back the output tensor,
Speaker 2: which would contain something like eighteen point ninety seven.
Speaker 1: The prediction for why what about more complex things like
Speaker 1: running an image classifier on mobile.
Speaker 2: The core process is the same convert to dot t
Speaker 2: flight use the interpreter. The trickier part is usually getting
Speaker 2: the image data into the right format before feeding it
Speaker 2: to the interpreter. How So, mobile platforms have their own
Speaker 2: image formats, like androids bitmap or iOS's uiimage. Your CNN model, however,
Speaker 2: probably expects input as a say, two to four by
Speaker 2: two two four x three tensor of floating point numbers
Speaker 2: normalized between zero one. So you need code to take
Speaker 2: the native image, resize it, extract the pixel values, maybe
Speaker 2: dealing with raw bite buffers and bit shifting for colors,
Speaker 2: normalize them and arrange them into the correct tensor shape.
Speaker 1: All right, There's some data wrangling involved, yeah, and some
Speaker 1: platform specific setup for the interpreter itself in the app project.
Speaker 2: Definitely. T flight also offers optimization, particularly quantization. During the
Speaker 2: conversion process, you can tell it to convert the model's
Speaker 2: weights from thirty two bit floats to say, eight bit integers,
Speaker 2: and that makes the model much smaller, often a four
Speaker 2: x reduction in file size, and it usually runs faster too,
Speaker 2: maybe two three x speed up on mobile CPUs or
Speaker 2: specialized hardware like edgetpus.
Speaker 3: Is there catch?
Speaker 2: There can be a small loss in accuracy because you're
Speaker 2: reducing precision. You always need to test the quantized model
Speaker 2: to see if the accuracy trade off is acceptable for
Speaker 2: your specific application.
Speaker 1: Okay, so t flight for native embedded What if you
Speaker 1: want mL in the browser or for a no JS backend, then.
Speaker 2: You're looking at pencerflow dot js. Tfs it lets you
Speaker 2: define train and run mL models entirely in JavaScript.
Speaker 1: You can actually train models in the browser.
Speaker 2: You can you can define a model layer by layer,
Speaker 2: similar to how you do it in Python. Using JavaScript APIs,
Speaker 2: you'd use TFJS tensors for your data. Training often involves
Speaker 2: a sinkle weight because it happens asynchronously in the browser.
Speaker 2: You can build that Y two x one model or
Speaker 2: even more complex things like image classifiers or models that
Speaker 2: work on CSV data, all within javascripts.
Speaker 3: That's pretty cool.
Speaker 1: But maybe the biggest win for web deevs is using
Speaker 1: models someone else has already trained.
Speaker 2: Absolutely, that's the power of pre converted JavaScript models. Places
Speaker 2: like TensorFlow, dot org and tfhub offer many sophisticated models
Speaker 2: already converted to the TFGS format, so.
Speaker 1: You can just load them and use them with minimal
Speaker 1: code exactly.
Speaker 2: There are models for toxicity detection and text image classification
Speaker 2: using things like mobile net, where you can just pass
Speaker 2: an mg tag pose detection with posnet that gives you
Speaker 2: coordinates of body joints from an image or video. You
Speaker 2: can integrate these powerful features into your web app pretty easily.
Speaker 1: Just load the model script, write a few lines of
Speaker 1: JavaScript to run inference.
Speaker 2: Pretty much, and you can even do transfer learning in TFJS.
Speaker 2: You can load a pre trained model like mobilenet, use
Speaker 2: a function like model dot infer mmg embtting to grab
Speaker 2: the internal feature embeddings for your own images, and then
Speaker 2: use those embeddings as input to train a small new
Speaker 2: TFJS model tailored to your specific classification task.
Speaker 3: Nice.
Speaker 1: Okay, one more deportment scenario. What if you need a dedicated,
Speaker 1: scalable server for running predictions, maybe lots of users hitting
Speaker 1: it at once.
Speaker 2: For that kind of robust production environment, you'd use TensorFlow serving.
Speaker 2: It's specifically designed to deploy TensorFlow models as a high
Speaker 2: performance inference server.
Speaker 3: What is it anal for you?
Speaker 2: It's built for low latency and high throughput. Crucially, it
Speaker 2: handles model versioning really well. You can deploy multiple versions
Speaker 2: of the same model, say V one and a new
Speaker 2: V two you just trained, and TensorFlow serving can manage
Speaker 2: serving requests to either version or transition traffic smoothly, so you.
Speaker 3: Can ab test models or roll out updates safely.
Speaker 2: Exactly. It typically exposes APIs like rest or gRPC. Your
Speaker 2: application sends an inference request with the data, TensorFlow Serving
Speaker 2: loads the correct model version, often managed via configuration files,
Speaker 2: runs the prediction efficiently and sends the result back. It's
Speaker 2: built for reliable, scalable production use.
Speaker 1: Okay, we've covered a ton of ground from the basic
Speaker 1: concepts through vision, language, time series, and now all these
Speaker 1: ways to deploy models. This really pulls together the practical
Speaker 1: side from Roney's book.
Speaker 2: Yeah, we started with that fundamental shift learning rules from
Speaker 2: data instead of writing them, and saw how tensilflow provides
Speaker 2: the platform for coders to do that.
Speaker 1: Then we dove into computer vision CNN's dealing with data
Speaker 1: limits using augmentation and transfer learning and.
Speaker 2: NLP tokenizing embeddings to capture meaning and RNNs like lstm's
Speaker 2: especially by directional ones to understand sequence and context even
Speaker 2: for generating texts.
Speaker 1: We touched on time series windowing data using CNN's and
Speaker 1: RNNs for prediction.
Speaker 2: And finally getting those models out there TFLight for devices,
Speaker 2: TFGS for the Web, and tf serving for scalable back
Speaker 2: end inference.
Speaker 1: It really feels like these tools make AI and mL
Speaker 1: much more practical for coders today. You don't need to
Speaker 1: be a deep research scientist to start building things exactly.
Speaker 2: The focus shifts to understanding the techniques when to use
Speaker 2: a CNN versus an LSTM, how to prepare your data,
Speaker 2: how to leverage pre train mode models, and applying them
Speaker 2: to your problems, which leads.
Speaker 3: To a final thought.
Speaker 1: Maybe we talked about transfer learning using these powerful pre
Speaker 1: train models, and also about running models right on the
Speaker 1: device with t flight for speed and privacy. So thinking
Speaker 1: about those capabilities combined, what kinds of really complex, maybe
Speaker 1: even personalized, intelligent features could you start imagining for the
Speaker 1: applications you build things that maybe seemed impossible just a
Speaker 1: few years ago, but are now potentially within reach for
Speaker 1: a code or using these tools