1:I[339756,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"LoadingBoundaryProvider"] 2:"$Sreact.fragment" 3:I[363178,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"ThemeProvider"] 4:I[63369,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 5:I[571829,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 6:I[339756,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 7:I[758298,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/1mio9khfe_4v7.js"],"default"] 8:I[837457,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 9:I[138093,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/3orq7nfqs6kfi.js"],"default"] a:I[505014,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/3orq7nfqs6kfi.js"],"default"] b:I[527930,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/3orq7nfqs6kfi.js"],"Button"] 19:I[168027,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default",1] :HL["/_next/static/chunks/2rv9re_scuvkh.css","style"] :HL["/_next/static/chunks/14a8efyk29rap.css","style"] :HL["/_next/static/media/0c89a48fa5027cee-s.p.2cyn07wtgehh0.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/media/0e54dc4a88da75bb-s.p.0m394x4vlmwm6.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/media/8d05cfa5faa8406c-s.p.1s123piy9_v1m.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/media/dc0d9adbac686440-s.p.3cik_s2si-ft-.woff2","font",{"crossOrigin":"","type":"font/woff2"}] 17:X 0:{"P":null,"c":["","tracks","ml-foundations","drawing-the-line"],"q":"","i":false,"f":[[["",{"children":["tracks",{"children":[["trackId","ml-foundations","d",[]],{"children":[["lessonId","drawing-the-line","d",[]],{"children":["__PAGE__",{},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4116],[["$","$L1",null,{"loading":[["$","div","l",{"className":"flex min-h-screen flex-col items-center justify-center gap-4","children":["$","p",null,{"className":"animate-pulse font-mono text-xs uppercase tracking-[0.2em] text-[#999]","children":"[ Loading… ]"}]}],[],null],"children":["$","$2","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/chunks/2rv9re_scuvkh.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","link","1",{"rel":"stylesheet","href":"/_next/static/chunks/14a8efyk29rap.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/chunks/43v7y6x3eg2ur.js","async":true,"nonce":"$undefined"}],["$","script","script-1",{"src":"/_next/static/chunks/12xh8d8esig5n.js","async":true,"nonce":"$undefined"}],["$","script","script-2",{"src":"/_next/static/chunks/18-gn3bjo15zd.js","async":true,"nonce":"$undefined"}],["$","script","script-3",{"src":"/_next/static/chunks/1msdpso3qlrt6.js","async":true,"nonce":"$undefined"}],["$","script","script-4",{"src":"/_next/static/chunks/3_fxm8bhygrh7.js","async":true,"nonce":"$undefined"}],["$","script","script-5",{"src":"/_next/static/chunks/3j9ojc-ugnhuo.js","async":true,"nonce":"$undefined"}],["$","script","script-6",{"src":"/_next/static/chunks/1tyt04182z3kp.js","async":true,"nonce":"$undefined"}]],["$","html",null,{"lang":"en","className":"space_grotesk_50bd8618-module__jnhQ_G__variable space_mono_e797c983-module__p8rDEW__variable doto_d3b4bd8a-module__c19I9a__variable dark h-full antialiased","data-scroll-behavior":"smooth","suppressHydrationWarning":true,"children":["$","body",null,{"className":"min-h-full flex flex-col","suppressHydrationWarning":true,"children":["$","$L3",null,{"attribute":"class","defaultTheme":"dark","forcedTheme":"dark","enableSystem":false,"children":["$","$L4",null,{"children":["$","$L5",null,{"children":[["$","a",null,{"href":"#main","className":"sr-only focus:not-sr-only focus:fixed focus:left-4 focus:top-4 focus:z-[100] focus:rounded-lg focus:bg-white focus:px-4 focus:py-2 focus:font-mono focus:text-xs focus:text-black","children":"Skip to content"}],["$","$L6",null,{"parallelRouterKey":"children","error":"$7","errorStyles":[],"errorScripts":[["$","script","script-0",{"src":"/_next/static/chunks/1mio9khfe_4v7.js","async":true,"nonce":"$undefined"}]],"template":["$","$L8",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":[["$","main",null,{"id":"main","className":"relative flex min-h-screen flex-col items-center justify-center overflow-hidden px-6 text-center","children":[["$","div",null,{"className":"absolute inset-0 opacity-30 [mask-image:radial-gradient(ellipse_70%_60%_at_50%_45%,black_30%,transparent_75%)]","children":["$","$L9",null,{"interactive":false,"className":"h-full w-full"}]}],["$","div",null,{"className":"relative z-10 flex flex-col items-center","children":[["$","div",null,{"className":"mb-8 flex h-12 w-12 items-center justify-center rounded-2xl border border-[#222] bg-[#111]","children":["$","$La",null,{"ref":"$undefined","icon":{"name":"compass","size":24,"node":[["circle",{"cx":"12","cy":"12","r":"10","key":"1mglay"}],["path",{"d":"m16.24 7.76-1.804 5.411a2 2 0 0 1-1.265 1.265L7.76 16.24l1.804-5.411a2 2 0 0 1 1.265-1.265z","key":"9ktpf1"}]]},"className":"h-5 w-5 text-[#999]","strokeWidth":2}]}],["$","p",null,{"className":"select-none font-doto text-[6rem] leading-none text-white sm:text-[9rem] md:text-[11rem]","children":"404"}],["$","h1",null,{"className":"mt-5 font-mono text-sm uppercase tracking-[0.08em] text-[#e8e8e8]","children":"[ This layer doesn’t exist ]"}],["$","p",null,{"className":"mt-3 max-w-sm text-sm text-[#999]","children":"The page you were looking for got lost in the network."}],["$","$Lb",null,{"data-slot":"button","className":"group/button inline-flex shrink-0 items-center justify-center rounded-full border border-transparent font-mono text-[13px] uppercase tracking-[0.06em] whitespace-nowrap transition-[background-color,border-color,color,transform] duration-200 ease-[var(--ease-out)] outline-none select-none active:not-aria-[haspopup]:scale-[0.97] disabled:pointer-events-none disabled:opacity-40 aria-invalid:border-[#d71921] [&_svg]:pointer-events-none [&_svg]:shrink-0 [&_svg:not([class*='size-'])]:size-4 bg-white text-black hover:bg-white/90 h-12 gap-2 px-6 has-data-[icon=inline-end]:pr-5 has-data-[icon=inline-start]:pl-5 mt-9","nativeButton":false,"render":"$Lc","children":["$Ld","Back to safety"]}]]}]]}],[]],"forbidden":"$undefined","unauthorized":"$undefined"}],"$Le","$Lf","$L10","$L11","$L12"]}]}]}]}]}]]}]}],{"children":["$L13",{"children":["$L14",{"children":["$L15",{"children":["$L16",{},null,false,null]},null,false,"$17"]},null,false,"$17"]},null,false,"$17"]},null,false,null],"$L18",false]],"m":"$undefined","G":["$19",["$L1a","$L1b"]],"S":false,"h":null,"r":"$undefined","s":"$undefined","a":"$undefined","l":"$undefined","p":"$undefined","d":"$undefined","b":"nT3d7wsrXuHqFdw6CXtyL"} 1c:I[522016,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/3orq7nfqs6kfi.js"],""] 1d:I[943582,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 1e:I[432597,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 1f:I[340100,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 20:I[595388,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 21:I[611015,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"default"] 23:I[897367,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"OutletBoundary"] 24:"$Sreact.suspense" 26:I[897367,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"ViewportBoundary"] 28:I[897367,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"MetadataBoundary"] c:["$","$L1c",null,{"href":"/learn"}] d:["$","$La",null,{"ref":"$undefined","icon":{"name":"arrow-left","size":24,"node":[["path",{"d":"m12 19-7-7 7-7","key":"1l729n"}],["path",{"d":"M19 12H5","key":"x3x0zl"}]]},"className":"$undefined"}] e:["$","$L1d",null,{}] f:["$","$L1e",null,{}] 10:["$","$L1f",null,{}] 11:["$","$L20",null,{}] 12:["$","$L21",null,{}] 13:["$","$2","c",{"children":[null,["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L8",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}] 14:["$","$2","c",{"children":[null,["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L8",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":[["$","main",null,{"className":"relative flex min-h-screen flex-col items-center justify-center overflow-hidden px-6 text-center","children":[["$","div",null,{"className":"absolute inset-0 opacity-25 [mask-image:radial-gradient(ellipse_70%_60%_at_50%_45%,black_30%,transparent_75%)]","children":["$","$L9",null,{"interactive":false,"className":"h-full w-full"}]}],["$","div",null,{"className":"relative z-10 flex flex-col items-center","children":[["$","p",null,{"className":"select-none font-doto text-7xl leading-none text-white md:text-8xl","children":"404"}],["$","h1",null,{"className":"mt-5 font-mono text-sm uppercase tracking-[0.08em] text-[#e8e8e8]","children":"[ Track not found ]"}],["$","p",null,{"className":"mt-3 max-w-sm text-sm text-[#999]","children":"It may still be in production — head back and pick another path through the network."}],["$","$Lb",null,{"data-slot":"button","className":"group/button inline-flex shrink-0 items-center justify-center rounded-full border border-transparent font-mono text-[13px] uppercase tracking-[0.06em] whitespace-nowrap transition-[background-color,border-color,color,transform] duration-200 ease-[var(--ease-out)] outline-none select-none active:not-aria-[haspopup]:scale-[0.97] disabled:pointer-events-none disabled:opacity-40 aria-invalid:border-[#d71921] [&_svg]:pointer-events-none [&_svg]:shrink-0 [&_svg:not([class*='size-'])]:size-4 bg-white text-black hover:bg-white/90 h-12 gap-2 px-6 has-data-[icon=inline-end]:pr-5 has-data-[icon=inline-start]:pl-5 mt-9","nativeButton":false,"render":["$","$L1c",null,{"href":"/learn"}],"children":[["$","$La",null,{"ref":"$undefined","icon":"$d:props:icon","className":"$undefined"}],"Browse tracks"]}]]}]]}],[]],"forbidden":"$undefined","unauthorized":"$undefined"}]]}] 15:["$","$2","c",{"children":[null,["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L8",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}] 16:["$","$2","c",{"children":["$L22",[["$","script","script-0",{"src":"/_next/static/chunks/0dy9k8ww2fujg.js","async":true,"nonce":"$undefined"}],["$","script","script-1",{"src":"/_next/static/chunks/3-gi5vr9grpva.js","async":true,"nonce":"$undefined"}],["$","script","script-2",{"src":"/_next/static/chunks/0dsymzc1mf__-.js","async":true,"nonce":"$undefined"}]],["$","$L23",null,{"children":["$","$24",null,{"name":"Next.MetadataOutlet","children":"$@25"}]}]]}] 18:["$","$2","h",{"children":[null,["$","$L26",null,{"children":"$L27"}],["$","div",null,{"hidden":true,"children":["$","$L28",null,{"children":["$","$24",null,{"name":"Next.Metadata","children":"$L29"}]}]}],["$","meta",null,{"name":"next-size-adjust","content":""}]]}] 1a:["$","link","0",{"rel":"stylesheet","href":"/_next/static/chunks/2rv9re_scuvkh.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 1b:["$","link","1",{"rel":"stylesheet","href":"/_next/static/chunks/14a8efyk29rap.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 2a:I[274764,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js","/_next/static/chunks/0dy9k8ww2fujg.js","/_next/static/chunks/3-gi5vr9grpva.js","/_next/static/chunks/0dsymzc1mf__-.js"],"default"] 17:C 22:["$","main",null,{"id":"main","className":"mx-auto w-full max-w-4xl px-6 py-10","children":["$","$L2a",null,{"track":{"id":"ml-foundations","title":"ML Foundations","tagline":"The core ideas every AI system is built on","description":"Data, features, training and evaluation — the fundamental mechanics of machine learning, taught visually.","level":"Beginner","prereq":["ai-literacy","math-for-ai"],"icon":"brain","hue":280,"certName":"Machine Learning Foundations Certificate","source":"Google ML Crash Course","modules":[{"id":"data-and-features","title":"Data & Features","description":"What models actually see","lessons":[{"id":"seeing-like-a-model","title":"Seeing Like a Model","description":"Features, vectors, and how raw data becomes numbers","duration":7,"xp":60,"steps":[{"type":"concept","title":"Everything becomes numbers","body":"A model can't see a photo or read an email — it sees a **vector**: a list of numbers. A photo becomes pixel intensities. An email becomes counts of words. A house becomes [bedrooms, square feet, age].\n\nChoosing *which* numbers describe your data — **features** — is one of the most important decisions in ML."},{"type":"concept","title":"A dataset is a matrix","body":"Line the vectors up and a dataset becomes a **matrix**: one row per example, one column per feature. A churn table of 50,000 customers × 40 columns is a 50,000 × 40 block of numbers — and the model's entire world.\n\nOne column is special: the **label** (`churned`), the thing you're predicting. Everything else is a **feature** — evidence the model may consult. Training is the search for a function from the 40 columns to the label.\n\nWorth internalizing early: the model sees *only* the matrix. It doesn't know what a customer is, can't read the contract, hasn't met the support calls. If a pattern exists in the world but not in the columns, it doesn't exist for the model.","callout":{"kind":"insight","text":"Rows are examples, columns are evidence, and the label is the question. If it isn't in the matrix, the model can't learn it."}},{"type":"visualization","title":"Explore embedding space","component":"embeddings","caption":"Words and images become points in space — similar things land close together. Drag to explore."},{"type":"concept","title":"Same object, many featurizations","body":"There's no single 'correct' vector for an object — only choices. An email could become:\n\n- **Word counts**: 20,000 dimensions of 'how many times did each word appear'\n- **TF-IDF**: the same counts, reweighted so rare words shout louder\n- **An embedding**: a few hundred dense numbers learned so similar emails land nearby\n\nEach is a different answer to 'what about this email matters?' Word counts preserve the literal; embeddings capture the semantic; a hand-built `num_exclamation_marks` captures a style. The featurization defines what the model *can* see — no algorithm recovers signal the encoding threw away.","callout":{"kind":"analogy","text":"Featurization is the model's eyeglass prescription. The world doesn't change when you swap lenses — but what's legible through them does."}},{"type":"quiz","question":"A row in a training table represents:","options":["A single feature","One model parameter","One example — a customer, an email, a house — measured across all features","A cluster of similar columns"],"answer":2,"explanation":"Each row is one example with its feature values in the columns. Models learn patterns across rows; features describe within a row. The label column holds the answer being predicted."},{"type":"concept","title":"Three tests before a column earns a dimension","body":"Before a column earns a dimension, run it through three tests:\n\n- **Is it related to the label?** `square_feet` plausibly moves price; `listing_id` doesn't — it's a barcode, not a measurement\n- **Will it exist at prediction time?** `days_on_market` is knowable when you price the house; `final_sale_price` obviously isn't — that's the answer wearing a costume\n- **Does it vary?** A column that's `USA` for 99.9% of rows carries almost no information; you can't learn from a constant\n\nMost 'model problems' are really column problems: the signal was never offered, or the answer was leaked in disguise.","callout":{"kind":"warning","text":"The second test is where production models die. A feature that's unavailable — or subtly derived from the future — at the moment of prediction is leakage, not signal."}},{"type":"quiz","question":"Which feature best satisfies the three tests for a loan-default model scored at application time?","options":["`borrower_credit_utilization` — measurable now and plausibly related to repayment","`approval_decision` — it determines default","`borrower_lifetime_default_flag` — perfectly predictive","`application_row_number` — unique per applicant"],"answer":0,"explanation":"Utilization is known at application time and causally related to repayment. The lifetime flag encodes the future, the row number is a barcode with no signal, and the approval decision is the label's twin — pure leakage."},{"type":"concept","title":"More features ≠ more signal","body":"Every column you add costs something: a dimension of space the model can carve, a chance to fit noise, a maintenance burden in production. 800 random-ID columns let a model reach 97% training accuracy by giving every training point its own private corner of space to hide in.\n\nTwo cheap audits practitioners run:\n\n- **The correlation scan** — features correlated above ~0.95 are usually one measurement wearing two units (`weight_kg`, `weight_lb`); drop one\n- **The importance audit** — fit a quick model and check what actually contributes; a feature no model uses earns a delete, not a debate\n\nFeature selection isn't a loss of information. It's information triage — removing what hides the signal."},{"type":"activity","title":"Try it yourself","activity":"neuron-lab"},{"type":"quiz","question":"Before a model can process an email, the email must first become:","options":["A summary","A decision tree","An image","A vector of numbers (features)"],"answer":3,"explanation":"Models operate on numeric vectors. Feature extraction converts raw data — text, images, records — into numbers a model can process."}],"challenge":[{"question":"A hospital trains a model to predict 30-day readmission risk *at the moment of discharge*. Its strongest feature turns out to be `followup_visit_within_30d` — whether the patient actually returned. Why is this a problem?","options":["It isn't — strong predictors should always be kept","The feature can only exist after the window being predicted — it encodes the future, so it won't exist when the model has to decide","Binary features are always bad features","The column needs normalization before use"],"answer":1,"explanation":"A feature that records what happened *after* the prediction point smuggles the answer into the inputs. It looks brilliant in training and is simply unavailable at the moment the model must act — the most expensive kind of feature bug."},{"question":"Your churn model uses 20 carefully chosen features. A colleague adds 800 columns of random IDs and sensor noise 'just in case.' Training accuracy climbs from 84% to 97%; test accuracy drops. What happened?","options":["The model needs still more features to recover","The test data must be corrupted","Nothing unusual — more features always raise variance this way","The noise columns gave the model hundreds of extra dimensions along which to memorize the training set"],"answer":3,"explanation":"Every feature is another dimension the model can carve to separate the training points. Columns carrying no real pattern invite pure memorization — which is why more features isn't the same as more signal."},{"question":"Two features, `weight_kg` and `weight_lb`, measure the same quantity in different units. You feed both into a linear model. The most likely effect?","options":["The model can't train — perfectly correlated features cause an error","Accuracy roughly doubles from the extra signal","Little harm to predictions, but no new information — the second column says nothing the first didn't","The two features cancel out and both get ignored"],"answer":2,"explanation":"A unit conversion is a perfectly correlated copy — it carries zero additional signal. Most models tolerate the redundancy, but the feature space inflates without buying anything the model couldn't already see."}]},{"id":"train-test-split","title":"The Test Your Model Can't See","description":"Train/test splits and why memorization isn't learning","duration":6,"xp":55,"steps":[{"type":"concept","title":"The exam you can't cheat on","body":"A student who memorizes the practice exam but can't solve new problems hasn't learned — they've memorized. Same for models.\n\nSo we hide part of the data — the **test set** — and only evaluate on it at the end. Performance on unseen data is the only honest measure of whether the model learned *general* patterns.","callout":{"kind":"insight","text":"Training accuracy tells you how well the model memorized. Test accuracy tells you how well it learned."}},{"type":"concept","title":"The mechanics of an honest split","body":"Say you have 100,000 rows of fraud data — 1% positive, so 1,000 fraud cases. The standard recipe:\n\n- **Shuffle first** — data often arrives sorted by date or class; splitting unshuffled hands the test set a different distribution than the training set\n- **Stratify** — sample so each split keeps ~1% positives, or chance may starve one side of the rare class\n- **Freeze the split** — random seed fixed, committed, never re-rolled\n\nAn honest 80/20 gives you 800 fraud cases to learn from and 200 to be tested on. Both numbers matter — one feeds the model, the other feeds your confidence in it.","callout":{"kind":"insight","text":"Stratification isn't optional for rare classes: at 1% prevalence, a plain random split can leave a split nearly empty of positives — the test then grades the model on a population that doesn't exist."}},{"type":"quiz","question":"Why does stratified splitting matter most on a dataset that's 1% positive?","options":["A plain random split can leave one side with almost no positives — the evaluation then measures nothing","It guarantees balanced 50/50 classes","It speeds up training","It prevents the model from seeing the label"],"answer":0,"explanation":"At 1% prevalence, chance alone can dump most positives into one side. Stratification preserves the class ratio in each split so the test set actually contains the rare thing you're trying to catch."},{"type":"visualization","title":"Overfitting, visualized","component":"overfitting","caption":"Increase complexity and watch the model memorize noise — train error drops, test error rises."},{"type":"concept","title":"When rows aren't independent","body":"The plain split assumes every row is a fresh draw. Reality disagrees:\n\n- **3 scans from the same patient** share that patient's anatomy — split by row and the model memorizes the patient, acing 'unseen' data that isn't\n- **Repeated sessions from one user** — split by row and the 'test user' was never new\n- **Time-ordered rows** — split randomly and the future bleeds into the past\n\nThe fix: split by **entity**, not by row — all of a patient's scans, all of a user's sessions, stay on one side. The test set should simulate deployment: genuinely new patients, users, and days.","callout":{"kind":"warning","text":"Group leakage is the most expensive split bug in industry: metrics glow, the model ships, and the first truly new entity breaks it."}},{"type":"quiz","question":"A dataset has 5 orders per customer. The honest way to split is:","options":["Random 80/20 by row","All 5 orders per customer in the same split — split by customer_id","The first 80% of rows chronologically, always","Duplicate the minority rows first"],"answer":1,"explanation":"Splitting by entity keeps every customer's orders together, so the test set measures generalization to *new* customers — which is what deployment actually demands. Random row splits leak identity."},{"type":"concept","title":"How much test is enough","body":"The test set answers a statistical question — 'how well does this generalize?' — so it needs enough of whatever is rare to answer it. If 1 in 1,000 transactions is fraud, a 500-row test set likely contains zero positives and can tell you nothing about recall.\n\nPractitioner heuristics:\n\n- **Hundreds of the rare class** in test is the floor for claiming anything about it\n- **Small margins need big test sets** — distinguishing 91.2% from 91.8% takes thousands of examples, not hundreds\n- **When data is scarce**, cross-validation reuses every row as test data once — the subject of a later lesson\n\nThe test set isn't a tax on training data. It's the budget that buys a trustworthy number."},{"type":"concept","title":"The hundred-peeks problem","body":"One peek at the test set is survivable. A hundred decisions guided by it isn't — and selection pressure works whether the peeking is deliberate or just random chance.\n\nRe-split until a seed scores 90%, and you've found the max of many draws, not the true performance. Try 20 architectures and report the best test score — same story: you optimized against the test set through your choices, and its number is now inflated by exactly the amount you selected for.\n\nThe discipline is cheap: make decisions on validation data, look at the test set once, at the end. A test set used repeatedly isn't a test set — it's a validation set with good PR."},{"type":"activity","title":"Try it yourself","activity":"lr-lab"},{"type":"quiz","question":"Why do we keep a test set separate during training?","options":["To honestly measure whether the model learned general patterns, not memorized","To speed up training","To reduce the dataset size","To satisfy regulators"],"answer":0,"explanation":"Evaluating on unseen data reveals generalization — whether the model captured real patterns or just memorized the training examples."}],"challenge":[{"question":"Your dataset arrives sorted: all 50,000 fraud examples first, then 950,000 legit ones. You take the last 20% as the test set and score 100% — yet the model is useless. Why?","options":["950,000 rows is too much data for one split","Twenty percent was too small a test set","The test slice contained zero fraud — the model learned 'always say legit' and the metric couldn't see it","Fraud data can't be split at all"],"answer":2,"explanation":"A contiguous slice of ordered data comes from a different distribution than the training rows — here, a test set with no positives at all. Shuffle (and stratify) first, so the split actually simulates unseen data."},{"question":"A teammate re-splits the data with different random seeds until one split produces a 90% test score, then reports that number. What went wrong?","options":["Nothing — some splits are just luckier than others","Shopping for a favorable split is tuning on the test set — the reported number is the max of many tries, not an honest estimate","He should have used 80/20 instead of 70/30","The seed should have been fixed at 42"],"answer":1,"explanation":"Selecting the best outcome across many test evaluations optimizes against the test set itself. Each peek spends some of its honesty — enough peeks and it becomes a validation set with good PR."},{"question":"A medical-imaging dataset has 3 scans each from 2,000 patients. Rows are randomly split 80/20, test accuracy is stellar — and the model fails on new hospitals. The likely cause?","options":["Not enough scans per patient","80/20 is the wrong ratio for images","The model needed a larger learning rate","The same patients appear in both splits — the model memorized patients, not pathology"],"answer":3,"explanation":"Random row splits ignore grouping: scans from one patient share that patient's scanner, anatomy, and quirks. Splitting by patient keeps every group on one side, so the test set measures generalization to *new* patients."}]},{"id":"garbage-in","title":"Why Data Quality Wins","description":"More data vs. better data — and why clean beats big","duration":6,"xp":55,"steps":[{"type":"concept","title":"More isn't better — better is better","body":"The industry cliché is 'just get more data'. But a million mislabeled examples teach a million wrong lessons. Audits of famous benchmark datasets have found ~6% of labels are simply wrong — and models trained on them learn the errors faithfully.\n\nThree quality killers to watch for:\n\n- **Label errors** — wrong answers baked into training data\n- **Duplicates** — the same example counted twice, inflating confidence\n- **Leakage** — test information sneaking into training, making scores meaningless"},{"type":"concept","title":"Leakage: the silent score inflator","body":"**Leakage** is when training data contains information that wouldn't exist at prediction time — and it's the most dangerous quality bug because it makes models look *better*, not worse.\n\nClassic case: predicting hospital readmission, and a 'patient ID' column secretly encodes that frequent patients are readmitted most. The model gets 98% accuracy on the test set — and fails instantly in production, where that shortcut doesn't exist.","callout":{"kind":"warning","text":"Suspiciously good results are a data-quality alarm, not a success. If a metric looks too good to be true, hunt for leakage before celebrating."}},{"type":"quiz","question":"A model achieves 99% accuracy on its test set but fails immediately in production. The most likely cause is:","options":["Production hardware is slower","The model was too small","The test set was too large","Leakage — training features contained information unavailable at prediction time"],"answer":3,"explanation":"Leakage lets the model learn shortcuts from information it won't have in production — inflated test scores, broken reality. It's the signature of a data bug, not a modeling win."},{"type":"concept","title":"Duplicates and the fake confidence","body":"If the same example appears in both train and test sets — easy to do when data is scraped from the web or sampled sloppily — the model 'predicts' it by memorizing, not learning.\n\nWeb-scale image sets famously contained near-duplicates of their own test photos. The fix is boring but mandatory: **deduplicate**, and split data by *entity* (all photos of patient X in train OR test, never both)."},{"type":"concept","title":"What quality actually means","body":"Quality isn't just 'correct labels'. A perfectly labeled dataset can still be useless if it doesn't cover the cases the model will face — a face recognizer trained only on daylight photos fails at night.\n\nThe practitioner's rule: a smaller dataset that's *accurate and representative* almost always beats a massive messy one — and it's cheaper to train on.","callout":{"kind":"warning","text":"You can't out-train bad data. No amount of model sophistication fixes examples that were wrong to begin with."}},{"type":"quiz","question":"A team doubles its dataset by scraping noisy, poorly labeled examples. The most likely result is:","options":["The model improves automatically because bigger is always better","Nothing changes","The model gets worse or learns the errors — more bad data doesn't help","Training becomes impossible"],"answer":2,"explanation":"Models faithfully learn whatever patterns are in the data — including mislabels and noise. Doubling a dataset with low-quality data usually hurts or wastes compute."},{"type":"concept","title":"Distribution shift: data expires","body":"Even perfect data has a shelf life. The world changes — customers age, fraud adapts, a pandemic rewires shopping behavior — and yesterday's distribution stops matching today's. This is **distribution shift**, and it's why deployed models degrade silently.\n\nThe defense is monitoring: track whether incoming data still looks like training data, and retrain when it drifts. Data quality isn't a one-time cleaning — it's maintenance."},{"type":"concept","title":"The data-cleaning loop nobody photographs","body":"Real teams spend ~80% of a project on data work: **profile** (what's in each column?), **validate** (rules that catch impossible values), **deduplicate**, **document lineage** (where did this row come from?).\n\nIt's unglamorous and completely decisive. The models that survive production are built by teams who treat data as a product — versioned, audited, and owned — not a download.","callout":{"kind":"insight","text":"Ask any ML team what moved their metric most last quarter. 'We cleaned the training data' beats 'we changed the architecture' almost every time."}},{"type":"activity","title":"Try it yourself","activity":"threshold-lab"},{"type":"quiz","question":"Why should train/test splits be made by entity (e.g., patient) rather than by row?","options":["It makes the files smaller","Rows from the same entity in both sets let the model memorize instead of generalize","Entities are easier to index","It's required by law"],"answer":1,"explanation":"If different rows of the same patient (or user, or photo) land on both sides of the split, the model recognizes the entity rather than learning the task — test scores collapse into memorization scores."}],"challenge":[{"question":"A fraud model trained on last year's data performs beautifully in backtests but misses a new fraud pattern weekly. What's the data-quality gap?","options":["The model needs more layers","Coverage — the training data doesn't represent the cases the model now faces; data quality means representative, not just correct","The test set was too small","Fraud is impossible to predict"],"answer":1,"explanation":"A perfectly labeled dataset can still fail if it doesn't cover current cases. Fraudsters adapt; a static dataset becomes unrepresentative — quality is about matching deployment reality."},{"question":"Which is the most reliable early symptom of data leakage?","options":["Training loss decreases slowly","Test metrics that look too good relative to the difficulty of the problem","The model takes a long time to train","Some features have missing values"],"answer":1,"explanation":"Leakage inflates metrics rather than degrading them — it's the only data bug that *rewards* you. Implausibly good scores relative to problem difficulty are the classic tell."},{"question":"A team finds 6% of labels are wrong but can't afford re-labeling everything. The best strategy is:","options":["Train anyway — deep learning handles noise","Prioritize cleaning the high-leverage subset (test set first, then ambiguous/confidently-wrong samples found via model disagreement)","Throw away the noisy 6%","Average the labels"],"answer":1,"explanation":"Clean the test set first — you can't trust evaluation on wrong labels — then triage training labels by finding examples where confident models disagree with the label. Targeted cleaning beats blanket effort."}]}]},{"id":"core-algorithms","title":"Core Algorithms","description":"Regression, classification, and decision boundaries","lessons":[{"id":"drawing-the-line","title":"Drawing the Line","description":"Classification as carving up space","duration":8,"xp":70,"steps":[{"type":"concept","title":"Classification is geometry","body":"Every classifier draws a **decision boundary** through feature space — everything on one side is class A, the other side class B.\n\nLinear models draw straight lines. Neural networks can carve arbitrarily complex shapes. The art is matching boundary complexity to the problem."},{"type":"concept","title":"The boundary is an equation","body":"A linear classifier computes a score like `0.7·income_k − 0.4·missed_payments − 3` and predicts 'approve' when it's positive. The decision boundary is the surface where the score equals zero — a line in 2D, a plane in 3D, a hyperplane beyond.\n\nConcrete: an applicant earning 50k with 2 missed payments scores `0.7·50 − 0.4·2 − 3 = 35 − 0.8 − 3 = 31.2` → approve. The boundary itself is every point where the score vanishes — applicants sitting exactly on it are coins the model can't call.\n\nThe weights set the boundary's slope; the constant slides it around. Training is just choosing which line to draw.","callout":{"kind":"insight","text":"Learning a linear model = learning one vector of weights. All that machinery — loss functions, gradient descent, epochs — exists to pick the numbers that orient a single flat surface."}},{"type":"visualization","title":"Carve the space","component":"decision-boundary","caption":"Try different models and datasets. Notice when simple boundaries win — and when they can't possibly work."},{"type":"quiz","question":"On data where positives form a ring around a cluster of negatives, a linear classifier scores ~50%. Why?","options":["It needs more epochs","A straight line can't express 'inside vs outside a ring' — the required boundary is a closed shape","The features need binning","Linear models can't handle two dimensions"],"answer":1,"explanation":"One straight cut can't enclose a region — ring and checkerboard patterns demand curved boundaries. No amount of training fixes a shape the model family can't draw: that's a representation limit, not an optimization failure."},{"type":"concept","title":"Two failure shapes: too flat, too wiggly","body":"Boundaries fail in opposite directions:\n\n- **Too simple**: a straight line through a checkerboard scores 50% forever — **underfitting**, a bias the model can't escape no matter how long you train\n- **Too complex**: a fractal threading every point scores 100% on training and collapses on new data — **overfitting**, variance chasing noise\n\nThe art sits between: the simplest boundary that captures the real pattern. Complexity should be earned by validation performance, not purchased because it's available."},{"type":"concept","title":"Distance to the boundary is confidence","body":"A point sitting deep inside class A's region is a confident call; a point grazing the boundary is a coin flip wearing a uniform. The score's magnitude — how far past zero it lands — is a working confidence meter.\n\nPractitioners exploit this constantly: route confident predictions to automation, and send the near-boundary cases — the applicants the model barely approves — to human review. The boundary isn't just a separator; its neighborhood marks exactly where the model knows it might be wrong.","callout":{"kind":"insight","text":"The most valuable output isn't 'class A' — it's 'class A, barely.' The strip along the boundary is where errors cluster, and where a second opinion pays for itself."}},{"type":"quiz","question":"A model approves every loan where `score > 0`. Two applicants score +0.01 and +8.3. What differs?","options":["The first sits on the boundary — a borderline call where error risk concentrates; the second is a confident yes","Nothing — both are approved identically","The first should be auto-denied","The second must be misclassified"],"answer":0,"explanation":"Magnitude near the boundary measures fragility: nudge the features or the weights slightly and +0.01 flips. Distance from the boundary is a working proxy for confidence — borderline cases are where review earns its keep."},{"type":"concept","title":"Every boundary prices its mistakes","body":"Shift a boundary and you don't just move errors — you *convert* one kind into another. Drag the 'fraud' line toward suspicion and more innocent cards get declined; retreat it and more fraud slips through.\n\nThis is why 'draw the best line' is underspecified: the best line depends on the cost of each side's mistakes. A screening test sweeps the boundary toward sensitivity; a banhammer retreats toward certainty. The geometry is fixed by data — the position along it is a decision about which errors you can afford."},{"type":"activity","title":"Try it yourself","activity":"neuron-lab"},{"type":"quiz","question":"A decision boundary is:","options":["The edge of the dataset","The maximum allowed error","The surface separating a classifier's predicted classes in feature space","A type of neural network"],"answer":2,"explanation":"Classifiers partition feature space into regions. The surface between regions of different predicted classes is the decision boundary."}],"challenge":[{"question":"On a checkerboard dataset — positives where `x` and `y` signs agree, negatives where they differ — a linear classifier scores 50% no matter how you tune it. What's the real problem?","options":["Not enough training epochs","The learning rate is too low","The dataset is too small to learn from","No straight line separates classes arranged in an XOR pattern — the boundary shape can't exist in a linear model"],"answer":3,"explanation":"A linear model can draw exactly one straight cut. XOR-style patterns demand a boundary that bends — you need a nonlinear model or engineered features before any amount of tuning changes the outcome."},{"question":"Model A draws a smooth curve with 90% training accuracy. Model B draws a fractal that threads between every point for 100%. On new data, what should you expect?","options":["B wins — 100% beats 90%","They tie — the training gap doesn't matter","A wins — B's boundary memorized noise and won't survive contact with unseen points","B wins if the new data is similar enough"],"answer":2,"explanation":"A boundary contorted to reach every training point is describing their noise, not the underlying pattern. The simpler curve — the one with slack — almost always travels better to new data."},{"question":"Two classifiers learn the same data. One produces a clean elliptical boundary; the other a staircase of tiny axis-aligned rectangles approximating the same ellipse. The staircase model is most likely a:","options":["Decision tree — single-feature splits can only cut parallel to an axis, so curves become stair-steps","Logistic regression","k-nearest neighbors","Neural network with smooth activations"],"answer":0,"explanation":"Each tree split tests one feature at a threshold — a horizontal or vertical cut. Approximating a diagonal or curved boundary forces a stack of small axis-aligned steps, the telltale signature in the visualization."}]},{"id":"gradient-descent-deep","title":"Gradient Descent, Properly","description":"Learning rate, local minima, and the descent loop","duration":8,"xp":70,"steps":[{"type":"concept","title":"The engine of all of AI","body":"Nearly every model you've heard of — GPT, image generators, recommenders — was trained by some flavor of **gradient descent**. The gradient points uphill; we step downhill; repeat.\n\nThe **learning rate** controls step size. It's the single most important hyperparameter: too large, training diverges; too small, it never finishes."},{"type":"concept","title":"One step, computed","body":"Take the simplest possible loss: `L(w) = w²`, gradient `2w`. Start at `w = 3` with learning rate `0.1`:\n\n- Step 1: gradient `= 6`, update `w = 3 − 0.1·6 = 2.4`\n- Step 2: gradient `= 4.8`, update `w = 2.4 − 0.48 = 1.92`\n- Step 3: `w = 1.536`…\n\nEach step is smaller than the last — the gradient shrinks as you approach the minimum, so descent naturally eases off the gas. That self-braking is why a fixed step size works at all.\n\nNow crank the rate to `1.1`: `w = 3 − 3.3 = −0.3`, then `−0.3 + 0.66 = 0.36`, then `−0.43`… each step overshoots and lands *higher* than the last. Same math, explosive outcome — the only difference is step size.","callout":{"kind":"insight","text":"The update rule is one line: `w ← w − lr × gradient`. Everything else in deep learning is scale and plumbing around that line."}},{"type":"quiz","question":"With `L(w) = w²` and `w = −4`, the next descent step (lr = 0.1) moves w to:","options":["−4.8 — descent always decreases w","0 — one step reaches the minimum","−4.1 — the step is always 0.1","−3.2 — the gradient is −8, so w = −4 − 0.1·(−8)"],"answer":3,"explanation":"The gradient `2w = −8` points downhill toward zero: `w − lr·gradient = −4 + 0.8 = −3.2`. Descending means subtracting the gradient — a negative slope pushes w *up* toward the minimum."},{"type":"visualization","title":"Tune the descent","component":"gradient-descent","caption":"Try learning rate 0.01, 0.5, and 1.5. Three completely different outcomes."},{"type":"concept","title":"Reading the loss curve","body":"The training curve is your instrument panel — three shapes carry diagnoses:\n\n- **Loss explodes or oscillates upward**: learning rate too big — each step overshoots into a higher wall. Halve it and retry\n- **Flat at a high value**: stuck — rate too small to matter, or a plateau where gradients nearly vanish\n- **Loss falls, stalls, falls again**: normal — descent often crosses flats before finding the next downhill corridor\n\nAnd the two-curve read: training loss down while validation loss climbs is the overfitting signature — keep walking and you're walking away from the model you want.","callout":{"kind":"warning","text":"When in doubt, halve the learning rate and re-run. It is the single highest-expected-value debug move in all of ML."}},{"type":"concept","title":"Valleys, saddles, plateaus","body":"The loss surface of a real model isn't one bowl — it's a mountain range:\n\n- **Local minima**: valleys you'd need to climb out of to do better; descent alone never escapes\n- **Saddle points**: flat in some directions, downhill in others — more common than minima in high dimensions, and a frequent cause of mysterious stalls\n- **Plateaus**: nearly flat plains where gradients are too small to move the needle\n\nTwo consequences practitioners live by: initialization matters — you land in the basin you start above — and a little noise helps, since stochastic gradients can rattle the model out of shallow basins that a perfect full-batch gradient never could."},{"type":"quiz","question":"Loss drops to a plateau for 40 epochs, then suddenly resumes falling. Most likely explanation?","options":["The model memorized the data","Descent crossed a flat saddle region where gradients were near zero, then found a downhill direction","The learning rate is too high","The dataset reshuffled"],"answer":1,"explanation":"Saddles produce exactly this signature: near-zero gradient for a long stretch, then escape once a downhill direction is found. It's why patience — and adaptive optimizers — exist."},{"type":"concept","title":"Mini-batches: noise as a feature","body":"Full-batch descent computes the exact gradient over all data — precise, expensive, and it walks straight into whatever minimum it approaches first. **Stochastic** gradients — computed on one example or a small **mini-batch** (typically 32–512) — are noisier but radically faster per step.\n\nThe noise is a feature, not a bug: random jitter lets the descent slip out of shallow minima and skip across narrow saddles. Mini-batches trade exactness for speed plus a dash of beneficial chaos — which is why nearly everything in AI trains on them, one **epoch** (a full pass over the data) at a time."},{"type":"activity","title":"Try it yourself","activity":"lr-lab"},{"type":"quiz","question":"If the learning rate is too high, training will most likely:","options":["Converge faster","Get stuck in a local minimum","Produce a smaller model","Overshoot the minimum and possibly diverge"],"answer":3,"explanation":"Oversized steps can jump past the minimum entirely, causing loss to increase or oscillate — divergence."}],"challenge":[{"question":"Training loss drops for three epochs, then doubles, then triples, then shoots to infinity. The most likely culprit?","options":["The dataset is too small","The model has too few parameters","The learning rate is so large each step overshoots the minimum and lands higher than before","The test set leaked into training"],"answer":2,"explanation":"Divergence is the signature of an oversized learning rate: each step jumps past the valley floor onto a higher wall, and the next gradient pushes even harder uphill. Halve it and try again."},{"question":"Two features have wildly different scales — `age` spans 0–100, `income` spans 0–1,000,000. Without normalization, gradient descent on this loss surface will most likely:","options":["Zigzag slowly across an elongated valley — a single step size can't fit both directions at once","Converge instantly — bigger gradients are faster","Fail to start entirely","Normalize the features automatically"],"answer":0,"explanation":"Mismatched scales stretch the loss surface into a narrow canyon where the gradient points across it, not along it. One learning rate can't serve both directions — which makes feature scaling a gradient-descent fix, not just hygiene."},{"question":"You train the same model twice from different random initializations. Run A lands at loss 0.31; run B stalls at 0.52. A reasonable interpretation?","options":["Run B's hardware is broken","Run B settled into a worse local minimum or plateau — descent only guarantees going downhill from where you start","The learning rate was definitely too high in run B","More epochs guarantee both runs reach 0.31"],"answer":1,"explanation":"Gradient descent is a local method — it follows the slope from its starting point, and complex loss surfaces have many basins. Different initializations genuinely lead to different endpoints; that's why restarts and good init matter."}]},{"id":"regression-intuition","title":"Regression: Fitting Lines That Predict","description":"Least squares, residuals, and how a line becomes a prediction","duration":7,"xp":65,"steps":[{"type":"concept","title":"Draw the line that explains the data","body":"Plot house price against square footage and the points form a cloud trending upward. **Regression** asks: what single straight line captures that trend best?\n\n'Best' has a precise meaning. Each point has a **residual** — the vertical gap between the real price and the line's prediction. **Least squares** picks the line that minimizes the sum of squared residuals.","callout":{"kind":"analogy","text":"Like lowering a ruler onto a scatter of points and tilting it until the points hug it as tightly as possible — the residuals are the gaps you can't close."}},{"type":"visualization","title":"Watch a curve fit — and overfit","component":"overfitting","caption":"Fit a curve to the points. A gentle line captures the trend; a wiggly curve chases noise — and fails on new data."},{"type":"concept","title":"Why square the errors?","body":"Why not minimize plain gaps? Two reasons. First, squared errors are **differentiable** — calculus can solve for the best line in one step instead of guessing. Second, squaring punishes big misses disproportionately: an error of 4 costs 16, not 4. The line works harder to avoid catastrophic misses than to shave small ones.\n\nThat choice has a cost: outliers dominate. One data-entry error at 50× the normal price can bend the whole line toward it.","callout":{"kind":"insight","text":"Least squares is a design decision, not a law of nature. Robust regression variants down-weight outliers precisely because squared errors give them too much voting power."}},{"type":"quiz","question":"Why does a single extreme outlier distort a least-squares fit so badly?","options":["Squaring makes big residuals cost disproportionately — one huge gap outvotes many small ones","Outliers shift the mean of the dataset","Outliers are always wrong data","Least squares can't handle more than 100 points"],"answer":0,"explanation":"The squared penalty scales superlinearly: a residual of 10 contributes 100 to the loss, a residual of 1 contributes 1. The optimizer will bend the line to avoid the 100 — even at the expense of all the 1s."},{"type":"concept","title":"From fitting to predicting","body":"Once the line is fit, prediction is trivial: plug in a new square footage, read off the price. `price = slope × sqft + intercept`\n\nRegression isn't just lines — the same idea fits curves, and with many features it becomes 'how does price depend on sqft, bedrooms, and age at once?' Real regression models are lines in many dimensions.","callout":{"kind":"warning","text":"Beware extrapolation: a line fit on 1,000–3,000 sq ft homes has no idea what a 20,000 sq ft mansion should cost."}},{"type":"concept","title":"Reading the coefficients","body":"Each fitted coefficient is a claim about the world: 'holding everything else fixed, one more bedroom adds $40k.' That *holding fixed* clause is the whole game — it isolates each feature's contribution.\n\nBut coefficients describe correlation inside your data, not guaranteed causation. If 'bedrooms' correlates with 'wealthy neighborhood', the model happily attributes neighborhood effects to bedroom count."},{"type":"quiz","question":"A regression says one extra bedroom predicts +$40k price. What can you NOT conclude from that?","options":["The model can interpolate within the data's range","The coefficient captured a correlation","Adding a bedroom to any house will increase its value by $40k","In this dataset, houses with more bedrooms tend to be worth ~$40k more, other features held equal"],"answer":2,"explanation":"Coefficients are associational: they describe patterns in the training data, not the causal effect of a renovation. Confounders (location, size) can sit inside that $40k."},{"type":"activity","title":"Try it yourself","activity":"threshold-lab"},{"type":"quiz","question":"In least-squares regression, what does the fitting algorithm minimize?","options":["The size of the dataset","The number of features","The slope of the line","The sum of squared gaps between the line's predictions and the real values"],"answer":3,"explanation":"Least squares chooses the line with the smallest total squared residual — the vertical distances between each real point and the line's prediction."}],"challenge":[{"question":"A house-price model fits beautifully on 1,000–3,000 sq ft homes but predicts $200k for a 20,000 sq ft estate. What's broken?","options":["The learning rate","Extrapolation — the line was never constrained outside the data's range, so it extends a trend that doesn't hold","The model needs more features","The training set was too small"],"answer":1,"explanation":"Regression guarantees nothing outside the observed range — the linear trend could flatten, curve, or invert there. The model doesn't 'know' it's extrapolating; it just extends the line."},{"question":"Adding 'ice cream sales' to a drowning-deaths regression shows a positive coefficient. The flaw in concluding ice cream causes drowning is:","options":["The coefficient is too small to matter","Confounding — a hidden variable (summer heat) drives both, and regression coefficients only encode correlation","Ice cream sales are quarterly data","The model needs regularization"],"answer":1,"explanation":"Coefficients capture correlation patterns, not mechanisms. With summer driving both variables, the model credits the effect to whichever feature it sees — classic omitted-variable bias."},{"question":"Two analysts fit the same data: one uses least squares, the other minimizes absolute errors. When will they disagree most?","options":["Always — the methods are incompatible","When the data has extreme outliers — squared errors chase them, absolute errors resist","Never — both find the same line","Only on categorical features"],"answer":1,"explanation":"Absolute-error regression is robust to outliers precisely because it doesn't square the penalty. The fits diverge exactly where extreme values live."}]}]},{"id":"working-with-data","title":"Working with Data","description":"Taming numbers, categories, and feature combinations","lessons":[{"id":"numerical-data-at-scale","title":"Numerical Data at Scale","description":"Normalization, outliers, and binning — why raw magnitudes lie","duration":8,"xp":70,"steps":[{"type":"concept","title":"One feature shouldn't outshout the rest","body":"Picture a dataset with two features: *age* (0–100) and *income* (0–1,000,000). To the model, every unit counts the same — so a $1 change in income looks identical to a 1-year change in age, and income's huge range lets it dominate every gradient step.\n\n**Normalization** rescales features onto a common footing so no column bullies the rest. Two workhorses:\n\n- **Min-max scaling** squashes everything into the range 0 to 1\n- **Z-score standardization** recenters each feature around a mean of 0 with a spread of 1\n\nAfter scaling, the model compares features on their merits — not their units.","callout":{"kind":"analogy","text":"Think of features as voters. Without normalization, the loudest voice wins regardless of wisdom. Scaling hands everyone the same-size megaphone."}},{"type":"concept","title":"The two workhorses, with numbers","body":"**Min-max**: `x′ = (x − min) / (max − min)`. For `age` observed from 20 to 60, a 40-year-old maps to `(40−20)/(60−20) = 0.5` — halfway through the range. Beware: a new extreme stretches the denominator and squashes everything previously scaled.\n\n**Z-score**: `x′ = (x − μ) / σ`. With mean 35 and standard deviation 10, that same 40 becomes `(40−35)/10 = +0.5` — half a standard deviation above average. Unlike min-max it has no fixed bounds: a value at +4σ stays +4σ, preserving the tail instead of clipping it.\n\nRule of thumb: bounded, roughly uniform features → min-max. Bell-shaped or heavy-tailed features — and any model that assumes normality — → z-score.","callout":{"kind":"insight","text":"Read a z-score aloud and it says something useful: '+2.3' means 'unusually high.' Scaling makes feature values interpretable, not just comparable."}},{"type":"visualization","title":"Scale changes the valley","component":"gradient-descent","caption":"Features on wildly different scales stretch the loss bowl into a narrow canyon — steps zigzag across it. Equal scales round the bowl, and the same learning rate walks straight down."},{"type":"quiz","question":"`income` ranges 20k–120k with mean 60k and standard deviation 20k. Under z-score scaling, an income of $100k becomes:","options":["+2.0","0.8","1.0","+4.0"],"answer":0,"explanation":"`(100k − 60k) / 20k = +2.0` — two standard deviations above the mean. Under min-max the same income lands at 0.8: same number, different ruler."},{"type":"concept","title":"The outlier dilemma","body":"An income of $40,000,000 turns up in your salary dataset. A data-entry error — or a CEO? What you should do depends entirely on the answer.\n\n- **Clip it**: cap values at, say, the 99th percentile\n- **Compress it**: a log transform shrinks the long tail so extremes count for less\n- **Keep it**: in fraud detection, the outlier *is* the signal — delete it and you've deleted your target\n\nAnd one extreme value quietly wrecks scaling: it drags the mean, min, and max until every ordinary value gets squashed into a tiny corner of the range.","callout":{"kind":"warning","text":"Compute scaling statistics on the training set only, then apply them to validation and test. Statistics computed on the full dataset leak test information into training."}},{"type":"concept","title":"Robust scalers for heavy tails","body":"When a feature has real, non-deletable extremes — salaries, transaction sizes, view counts — both workhorses stumble: min-max is hostage to its endpoints, and even the z-score's mean and σ get dragged by the tail.\n\nThe heavy-tail toolkit:\n\n- **Robust scaling**: use the median and interquartile range — `x′ = (x − median) / IQR`. A billionaire can't move the median, so the scale stays sane\n- **Log transforms**: `log(x)` compresses the tail geometrically — a 10× difference becomes a constant step — and often reveals a bell shape hiding inside a skewed one\n- **Winsorizing**: cap the top 1% at the 99th-percentile value before scaling\n\nAnd a reminder that saves real time: tree-based models need none of this — splits only ask 'is x < t,' a question whose answer survives any monotone transform.","callout":{"kind":"insight","text":"Check *why* you're scaling before you do. Gradient- and distance-based models need it; trees are immune to units entirely."}},{"type":"concept","title":"Binning: buckets beat lines","body":"Some relationships refuse to be a smooth curve. House prices jump at school-district borders; demand spikes at 6pm and collapses by 6:15.\n\n**Binning** chops a numeric feature into discrete buckets — latitude 34.0–34.2, 34.2–34.4, and so on — and lets the model learn a value for each. Sharp, local patterns become learnable where no straight line could express them.","callout":{"kind":"insight","text":"Binning turns a smooth number into categories — which means it pairs perfectly with the encodings in the next lesson."}},{"type":"quiz","question":"A salary column has a few legitimate $10M+ executives among thousands under $200k. Min-max scaling crushes everyone into 0–0.02. The cleanest fix?","options":["Normalize twice","Drop the executives — they're outliers","Log-transform first (or cap at the 99th percentile), then scale","Switch to one-hot encoding"],"answer":2,"explanation":"The tail is real signal, not noise — deleting it is wrong, and min-max stays hostage to it either way. A log compresses the extreme range before scaling; winsorizing caps it. Both let ordinary values reclaim the scale."},{"type":"concept","title":"Fit the scaler on train only","body":"Here's the leak in slow motion. Your test set contains the true maximum income — $9M — but the training set tops out at $400k. Fit min-max on the *full* dataset and every training value gets divided by 9 million: you've compressed the training features using a number the model was never supposed to know. The model indirectly learned 'incomes reach $9M out there.'\n\nThe discipline: split first. Fit the scaler — min, max, mean, σ, all of it — on the training rows alone. Freeze it. Apply those stored statistics to validation and test, even when test values land outside the training range — a test income beyond the train max maps above 1.0, and that's the honest outcome, not a bug.\n\nSame rule, memorably: anything that *learns a number from data* — scalers, imputers, encoders — is part of the model and trains on train only."},{"type":"activity","title":"Try it yourself","activity":"neuron-lab"},{"type":"quiz","question":"A model trains on *years of education* (0–25) and *account balance* (0–5,000,000). Without normalization, what most likely happens?","options":["Training fails with an error","Account balance's huge scale dominates the gradient updates","Years of education gets ignored because it's categorical","Nothing — models handle scale automatically"],"answer":1,"explanation":"Gradient steps scale with feature magnitude. A feature spanning millions produces updates thousands of times larger than one spanning tens, drowning out the smaller feature's signal. Normalization puts them on equal footing."}],"challenge":[{"question":"An engineer fits min-max scaling on the *entire* dataset, then splits into train and test. The pipeline runs cleanly — what's wrong?","options":["Min-max can't be applied before splitting","Nothing — scaling is unsupervised, so it can't leak","The test set should be scaled with its own min and max","The scaling statistics absorbed test-set values — the model indirectly saw the range of the data it was supposed to be surprised by"],"answer":3,"explanation":"Fitting any transform on all the data lets test values shape training preprocessing — a subtle leak. Fit scalers on the training split only, then apply the frozen transform to validation and test."},{"question":"In a fraud dataset, `transaction_amount` has a few extreme values near $5M while 99% sit under $500. Before deleting them as outliers, the key question is:","options":["Whether the values exceed three standard deviations","Whether they're errors or signal — in fraud detection the extreme transaction may be exactly what you're hunting","Whether there are more than ten of them","Whether z-scoring would shrink them"],"answer":1,"explanation":"An outlier is a data-entry error until proven guilty — or the whole point of the exercise. In fraud, intrusion, and failure detection, the tail *is* the target; clipping it deletes the signal."},{"question":"After min-max scaling `income`, every ordinary value gets crushed into 0.00–0.02 because one billionaire stretches the max. The best fix is:","options":["Clip the extreme or log-transform first, so the bulk of the data reclaims the range","Apply min-max a second time","Switch the feature to one-hot encoding","Increase the learning rate to compensate"],"answer":0,"explanation":"Min-max is hostage to its endpoints: a single extreme value compresses everything else into a sliver. Capping at a percentile or taking a log shrinks the tail before the scale gets set."},{"question":"House prices jump discontinuously at a school-district border — same street, different side, different price band. Which numeric treatment captures that best?","options":["Z-score standardization of latitude","A higher-degree polynomial in latitude","Binning latitude into small buckets, so each zone can learn its own value","Removing the border addresses as outliers"],"answer":2,"explanation":"Sharp, local jumps are nearly impossible for a smooth global function to express. Bucketing converts position into discrete cells, letting the model learn a separate price level per neighborhood."}]},{"id":"categorical-data","title":"Categorical Data","description":"One-hot, hashing, and when embeddings beat both","duration":8,"xp":75,"steps":[{"type":"concept","title":"Categories aren't numbers","body":"A `color` column holding red, green, and blue can't go into a model as text. But the obvious fix — red=1, green=2, blue=3 — is worse: it invents an ordering and a distance ('blue is bigger than green') that don't exist.\n\n**One-hot encoding** gives each category its own dimension instead:\n\n- red → [1, 0, 0]\n- green → [0, 1, 0]\n- blue → [0, 0, 1]\n\nNow every category is equidistant from every other — no fake order, no fake distances.","callout":{"kind":"warning","text":"ZIP code 90210 is a label, not a quantity — it isn't 'larger' than 02134. Any number that names a thing rather than measures it is categorical."}},{"type":"concept","title":"When the order is real: ordinal encoding","body":"One-hot exists because categories usually have no order. Sometimes they genuinely do — `size: S < M < L < XL`, `education: high school < bachelor's < master's`, `rating: poor < fair < good < excellent`.\n\nThese are **ordinal** features, and integer encoding is not only safe — it's *better*: `S=1, M=2, L=3` hands the model the ordering directly, in one column instead of four. The assumption is that the gaps are comparable — 'M to L' means roughly the same step as 'L to XL.' When that's false (letter grades? satisfaction buckets?), bin honestly or one-hot.\n\nThe discipline is one question: does this number *measure* something, or merely *name* it?","callout":{"kind":"warning","text":"ZIP codes are the classic trap — digits that name, not measure. 90210 isn't 'larger' than 02134. The integer test: would `category₁ + category₂` mean anything? If no → categorical."}},{"type":"quiz","question":"`satisfaction: poor / fair / good / excellent` — the best encoding is:","options":["One-hot — always the safest option","Hash into 8 buckets","Drop it — text can't be modeled","Ordinal integers 1–4 — the order is real and meaningful"],"answer":3,"explanation":"Genuinely ordered categories carry structure an integer scale expresses compactly. One-hot would work but discards the ordering the data handed you for free."},{"type":"concept","title":"When categories explode","body":"One-hot is elegant at 10 categories. At 10 million — every possible search query, say — each item becomes a 10-million-dimension vector of almost pure zeros. Memory explodes, and every item sits alone in its own corner of space.\n\nTwo escapes:\n\n- **Hashing**: run each category through a hash function that maps it into a fixed number of buckets. Collisions — two categories sharing a bucket — happen, but they're rare enough that models shrug them off.\n- **Embeddings**: learn a small dense vector per category, so similar categories land near each other — Monday ends up beside Tuesday.","callout":{"kind":"insight","text":"Rule of thumb: few categories → one-hot. Bounded memory or a huge vocabulary → hashing. Many categories whose relationships matter → embeddings."}},{"type":"concept","title":"The rare, the unseen, and the OTHER bucket","body":"Two long-tail problems lurk in every categorical column:\n\n- **Rare categories**: `country` has 200 values, but 40 appear fewer than 10 times — each gets a dimension backed by almost no data. Standard practice: collapse everything below a frequency threshold (say, <1%) into an `OTHER` bucket\n- **Unseen categories**: production serves `country = 'Cuba'`, which training never saw. One-hot encodes it as all zeros — a silent 'nothing here' the model was never tested on. Give the pipeline an explicit `UNKNOWN` bucket and route a fraction of training rows through it\n\nCategories you'll meet later but didn't see in training are guaranteed to exist. Build the bucket before production teaches you that."},{"type":"visualization","title":"Embeddings pack meaning into space","component":"embeddings","caption":"Instead of millions of near-empty dimensions, embeddings place each category in a few hundred dense ones — similar things land close together. Drag to explore the neighborhoods."},{"type":"concept","title":"One column too many: the dummy trap","body":"One-hot a 3-value `color` and you get three columns — but they carry only two independent pieces of information: `red + green + blue = 1`, always. Keep all three and a linear model faces a perfect linear dependency — the classic **dummy variable trap**.\n\nThe convention: drop one column (the 'reference' category, absorbed into the intercept) for linear models. Modern libraries and regularization often absorb the redundancy harmlessly, and tree models don't care at all — but when a linear model's coefficients explode into absurd magnitudes on perfectly correlated dummies, this is why."},{"type":"concept","title":"Target encoding: power and peril","body":"There's a fourth option the textbooks whisper about: encode each category by the *average label it produced in training* — `city = 'Chicago'` becomes `0.31`, the historical churn rate of Chicagoans. One column, massively informative, handles huge cardinality without dimension explosion.\n\nThe catch is leakage-by-construction: the feature was computed from the very labels you're predicting. On rare categories it's pure memorization — a city with 2 rows encodes their answers into every future prediction. The fixes are well-worn:\n\n- Compute encodings **out-of-fold** — each row's encoding uses only other rows' labels\n- **Smooth toward the global mean** — rare categories get shrunk back toward average, populous ones keep their estimate\n\nPowerful, standard in industry, and the single easiest way to fabricate a leaderboard-worthy lie.","callout":{"kind":"warning","text":"Any feature computed *from the target* — encodings, aggregations, counts — is a leak waiting for a pipeline bug. Out-of-fold or it's fiction."}},{"type":"quiz","question":"Encoding `city` as its historical default rate worked beautifully in training — but the column was computed on all rows including validation. The flaw?","options":["City can't be encoded numerically","Target encoding needs more categories","The feature was built from the labels it's supposed to predict — validation rows encoded their own answers","The rate should have been multiplied by 100"],"answer":2,"explanation":"Target encoding must be computed out-of-fold: each row's encoded value may only depend on other rows' labels. Computing it on the full dataset bakes the answer into the inputs — a leak that produces unbeatable backtests and useless models."},{"type":"activity","title":"Try it yourself","activity":"lr-lab"},{"type":"quiz","question":"A `country` feature has about 200 possible values. What's the most practical encoding?","options":["One-hot — 200 dimensions is completely manageable","Assign each country an integer from 1 to 200","A learned embedding — always the best option","Hash everything into 3 buckets"],"answer":0,"explanation":"Integer codes invent a false ordering, embeddings shine at huge vocabularies but are overkill here, and 3 hash buckets would collide constantly. For a few hundred categories, one-hot is simple and effective."}],"challenge":[{"question":"A teammate encodes `day_of_week` as 0–6 and `zip_code` as its literal digits, feeding both into a linear model. What's wrong with the zip-code column?","options":["Nothing — zip codes are already numbers","It should just be normalized to 0–1 like any number","Zip codes have too many digits for a linear model","The digits invent an ordering and distance — the model will treat 90210 as 'larger than' 02134, which is meaningless"],"answer":3,"explanation":"A number that names a thing rather than measures it is categorical in disguise. Treating zip codes as quantities claims 90001 + 9 ≈ 90010 — an arithmetic that corresponds to nothing real."},{"question":"Your model must handle `search_query` — 8 million distinct strings. Why does plain one-hot encoding break down here?","options":["One-hot only works for numeric columns","Each query becomes an 8-million-dimensional near-empty vector — memory explodes and every query sits alone, sharing nothing with similar queries","Strings can't be encoded at all","8 million categories means 8 million classes to predict"],"answer":1,"explanation":"At extreme cardinality, one-hot turns every item into a giant vector of zeros — expensive, sparse, and incapable of expressing that two similar queries are similar. Hashing or learned embeddings compress the space instead."},{"question":"Your one-hot encoder was fit on training data covering 150 countries. At prediction time a row arrives with `country = 'Cuba'` — never seen in training. What does the model most likely do?","options":["Refuse to run entirely","Automatically create a new dimension for it","Map it to the geographically nearest country's vector","Encode it as all zeros — the model sees 'no country at all,' and its behavior on such rows is untested"],"answer":3,"explanation":"One-hot only has columns for categories it saw. An unseen value typically falls back to an all-zeros row — a silent representation gap. Production pipelines need an explicit 'unknown' bucket or a scheme that tolerates novelty."},{"question":"A hashing trick maps every category into 1,000 buckets, and two unrelated categories collide into bucket 437. The model will:","options":["Crash on the collision","Automatically separate them again at prediction time","Treat the two categories as identical in that feature — a rare, tolerable accuracy cost in exchange for bounded memory","Lose all information from both categories"],"answer":2,"explanation":"Collisions merge distinct categories into one shared bucket, so the model can't tell them apart — but with enough buckets they're rare enough that the cost stays small. That's the whole trade: bounded memory for occasional confusion."}]},{"id":"feature-crosses","title":"Feature Engineering & Crosses","description":"When two weak features combine into a strong one","duration":7,"xp":70,"steps":[{"type":"concept","title":"When 1 + 1 is greater than 2","body":"Two features can be nearly useless alone and powerful together. Latitude alone tells you the average price of a *horizontal stripe* of a city; longitude alone, a *vertical stripe*. Neither pins down a neighborhood — but the pair locates a street corner.\n\n**Feature engineering** means turning domain knowledge into new columns: ratios, time-since-event, day-of-week. The sharpest tool in the kit is a **feature cross** — a synthetic feature combining two or more inputs so the model can see their interaction.","callout":{"kind":"analogy","text":"Latitude and longitude are like a Battleship guess: a row or a column means little. The hit only happens where they cross."}},{"type":"concept","title":"The crosses hiding in your table","body":"Many of the best features in production are disguised crosses — ratios and products that compress an interaction into one column:\n\n- `transaction_amount / account_age_days` — 'money moved per day of tenure' spikes exactly when new accounts move big funds\n- `rooms / household_size` — crowding, which neither raw column expresses\n- `revenue / support_tickets` — value per complaint, the ratio separating healthy growth from churning friction\n\nEach is domain knowledge made arithmetic. A worked example: account A — 30 days old, $900 moved. Account B — 3 days old, $2,700 moved. A moves $30/day; B moves $900/day. The ratio column sees the risk that neither input could show a linear model alone.","callout":{"kind":"insight","text":"Ratios are the cheap cross: one column, no cardinality explosion, and often the physically meaningful quantity. Before crossing categoricals, check whether the interaction you want is just a division."}},{"type":"quiz","question":"`balance` and `num_products` each weakly predict churn. Which engineered feature most likely captures 'spread thin across products'?","options":["balance / num_products — holdings per product, the interaction in one column","balance + num_products","balance − num_products","num_products²"],"answer":0,"explanation":"A customer with $50k in one product differs from $50k split across ten — same sum, different loyalty. The ratio compresses that interaction into a single learnable column."},{"type":"concept","title":"Crosses give simple models superpowers","body":"A linear model can only *add* feature effects — it can't multiply them. Hand it `latitude` and `longitude` separately and it will never find the street corner. Hand it a `lat × lon` crossed grid and it can learn a value per cell — nonlinearity, from a linear model.\n\nNeural networks learn their own crosses inside hidden layers, which is why hand-built crosses matter most for simple models — or when an interaction is so specific you want to guarantee the model sees it.","callout":{"kind":"insight","text":"A feature cross hands a linear model a nonlinear answer. A hidden layer is a machine for inventing crosses you didn't think of."}},{"type":"visualization","title":"Patterns no straight line can draw","component":"decision-boundary","caption":"On checkerboard-style data, neither axis alone separates the classes — crossed and nonlinear features carve it cleanly. Watch which models need help from feature engineering."},{"type":"concept","title":"The cardinality bomb","body":"Cross `city` (5,000 values) with `item_category` (2,000) and you mint 10 million candidate features — more columns than most datasets have rows. The consequences compound:\n\n- **Sparsity**: almost every cell of the cross appears a handful of times or never — dimensions with no data behind them\n- **Memorization**: a cell containing one training example is a private label for that row\n- **Cost**: memory, training time, and a model spending its capacity describing noise\n\nCrosses multiply cardinality the way multiplication multiplies numbers — always compute the product of the inputs' cardinalities before one-hotting the result."},{"type":"concept","title":"Cross responsibly: bucket first","body":"The practitioner's recipe for safe crosses:\n\n- **Bucket before crossing** — `hour` (24) × `day` (7) = 168 cells is fine; raw `lat` × `lon` is not. Bin latitude into 0.1° cells first, then cross — the grid gets expressive without exploding\n- **Keep cells populated** — a crossed cell needs enough examples to estimate a pattern; if most cells hold <30 rows, the cross is too fine\n- **Hash the result** — the same trick that tames huge vocabularies bounds a cross's memory at a fixed bucket count\n- **Cross what's weak-together** — a cross of two individually-weak features is where the magic hides; two strong features rarely need it\n\nThe goal isn't more columns — it's a column that says what neither parent could."},{"type":"quiz","question":"You want to cross `hour` and `zip_code` for a delivery model. The sensible order of operations?","options":["One-hot both, then multiply","Bucket zip to metro area first (~500 areas), then cross with hour — keeps cells populated","Cross raw values directly — 43,000 zips × 24 hours is fine","Skip it — crosses never help"],"answer":1,"explanation":"43k zips × 24 hours ≈ 1M cells, almost all empty. Coarsening the geographic key first keeps each crossed cell populated enough to estimate — the general rule: shrink cardinalities, then cross."},{"type":"activity","title":"Try it yourself","activity":"threshold-lab"},{"type":"quiz","question":"`hour_of_day` and `day_of_week` each weakly predict delivery demand, but together they predict it strongly. Best move?","options":["Cross them — 'Friday 6pm' is a feature neither can express alone","Drop both — they're too weak to help","Keep only the stronger of the two","Normalize them onto the same scale"],"answer":0,"explanation":"The signal lives in the interaction: Friday evening demand differs from Friday morning or Tuesday evening. A crossed feature lets even a linear model capture that combination."}],"challenge":[{"question":"Neither `hour` nor `is_weekend` alone predicts pool-hall demand — but Saturday-afternoon slots are packed. Your linear model fails. The fix is:","options":["Drop both features — they're individually weak","Double the learning rate and retrain","Cross them — 'Saturday 2pm' is a pattern neither feature can express on its own, and a linear model can't multiply them for you","Collect more rows of the same two features"],"answer":2,"explanation":"The signal lives entirely in the interaction. A linear model can only add the two effects; a crossed feature hands it the combination directly — nonlinearity from a linear model."},{"question":"You cross `city` (5,000 values) with `item_category` (2,000 values) and one-hot the result. What goes wrong?","options":["Nothing — more features always help","The cross explodes into 10 million mostly-empty buckets — sparsity, memory blowup, and almost no data per cell","Crosses can't be one-hot encoded","The model becomes too interpretable"],"answer":1,"explanation":"Crosses multiply cardinality: two big features become an enormous sparse grid where each combination has almost no examples — memorization with extra steps. Crosses pay off when their cells stay populated."},{"question":"When does a *hand-built* feature cross matter least?","options":["When the model is linear","When the two features are individually weak","When the interaction is the dominant signal","When the model is a deep network — hidden layers already learn interactions, so the cross mostly duplicates what the net invents itself"],"answer":3,"explanation":"Hand crosses earn their keep for models that can't express interactions — linear models, or cases where you want to guarantee a specific combination is visible. Hidden layers are a machine for inventing crosses you didn't think of."},{"question":"A fraud team notices risk spikes only when `account_age_days` is small *and* `transaction_amount` is large — each alone is unremarkable. Besides crossing them directly, what's the cleanest engineered feature?","options":["The arithmetic mean of the two features","`transaction_amount / account_age_days` — a ratio that compresses the same interaction into one column","The sum of the two features","One-hot encoding each feature independently"],"answer":1,"explanation":"Ratios and products of raw features are hand-made interactions — 'amount per day of tenure' rises exactly when young accounts move big money. Domain knowledge turned into a column is what feature engineering is."}]}]},{"id":"metrics-that-matter","title":"Metrics That Matter","description":"Why the number you optimize decides what you ship","lessons":[{"id":"accuracy-trap","title":"Accuracy Is a Trap","description":"Why a 99% accurate model can be worthless","duration":7,"xp":65,"steps":[{"type":"concept","title":"The 99.9% model that does nothing","body":"One transaction in 10,000 is fraudulent. A 'model' that answers *legit* every single time scores 99.99% accuracy — and catches zero fraud.\n\nThis is **class imbalance**: when one class is rare, the majority drowns the metric. Accuracy quietly becomes 'how often is the answer the common one?' — which has nothing to do with whether your model learned anything.","callout":{"kind":"warning","text":"Before celebrating accuracy, compute the lazy baseline: 'predict the majority class every time.' If your model barely beats a classifier that can't learn, it probably didn't."}},{"type":"concept","title":"Four honest numbers","body":"The **confusion matrix** sorts every prediction into one of four buckets, so each kind of mistake gets a name:\n\n- **True positive (TP)**: sick patient, flagged as sick\n- **False positive (FP)**: healthy patient, flagged — a false alarm\n- **False negative (FN)**: sick patient, missed entirely\n- **True negative (TN)**: healthy patient, correctly cleared\n\nAccuracy mashes all four into one number. But a missed cancer (FN) and a false alarm (FP) are wildly different mistakes — one number can't see the difference.","callout":{"kind":"insight","text":"Nearly every classification metric you'll ever meet — precision, recall, specificity — is just arithmetic on these four counts."}},{"type":"concept","title":"Do the arithmetic once","body":"10,000 transactions, 100 fraudulent. Your model flags 300 — 80 real frauds and 220 false alarms — and lets 20 frauds through.\n\nThe matrix: TP=80, FP=220, FN=20, TN=9,680.\n\n- **Accuracy**: (80+9,680)/10,000 = 97.6% — looks great\n- **Caught rate** (recall): 80/100 = 80% — decent\n- **Flagged-and-right** (precision): 80/300 ≈ 27% — three of four flagged customers are innocent\n- **False-alarm rate**: 220/9,900 ≈ 2.2% of legit transactions flagged\n\nFour counts, four different stories. The 97.6% headline is carried almost entirely by the 9,680 boring correct 'legit' answers — the part nobody was worried about.","callout":{"kind":"insight","text":"On imbalanced data, accuracy mostly reports how many easy negatives exist. The informative numbers live in the positive corner: what you flagged, and what you missed."}},{"type":"quiz","question":"Of 1,000 flagged items, 700 are true positives. Meanwhile 200 more positives were missed entirely. Precision and recall?","options":["P=70%, R=~78%","P=~78%, R=70%","P=70%, R=90%","P=90%, R=70%"],"answer":0,"explanation":"Precision = TP/(TP+FP) = 700/1,000 = 70%. Recall = TP/(TP+FN) = 700/900 ≈ 78%. Precision asks 'of my flags, how many were right'; recall asks 'of the real ones, how many did I get.'"},{"type":"concept","title":"Ask which mistakes, not how many","body":"Once you stop trusting accuracy, the right question shifts from *how often is it wrong?* to *which way is it wrong?*\n\n- A **spam filter** that bins your boss's email fails differently than one that lets spam through\n- A **cancer screen** that misses a tumor fails differently than one that orders an extra scan\n\nThe next lesson gives each direction of failure a name — and a dial to control it."},{"type":"concept","title":"When accuracy is honest — and what replaces it","body":"Accuracy isn't evil — it's blind. It reports correctly when:\n\n- **Classes are roughly balanced** — at 50/50 the lazy baseline scores ~50%, so 92% means something\n- **Both error types cost the same** — a digit recognizer where a misread 3 and a misread 7 are equally bad\n\nIt lies when one class is rare or mistakes are asymmetric — which is to say, most real problems. The professional reflex: compute the majority-class baseline first ('predict legit always' = 99%), then ask whether the model's margin *over* it justifies existing. A model scoring 97% where 'always say no' scores 99% isn't a model — it's worse than a coin that only lands one way."},{"type":"quiz","question":"Your dataset is 70% class A / 30% class B. A model scoring 78% accuracy is:","options":["Clearly skilled — 78% is high","Definitely better than baseline","Only mildly informative — 'always predict A' already scores 70%, so the margin over baseline is just 8 points","Underfit, by definition"],"answer":2,"explanation":"Accuracy only means something against the baseline it must beat. Here the lazy baseline gets 70% for free, so the model's real contribution is 8 points — worth checking, but a far cry from what '78%' advertises."},{"type":"concept","title":"Beyond binary: macro vs weighted","body":"With ten classes instead of two, accuracy hides a second trap inside the first. Suppose three classes cover 95% of rows and seven are rare:\n\n- **Weighted/overall accuracy**: dominated by the common classes — ace the big three and you can score 95% while missing every rare class\n- **Macro-averaged metrics**: compute per-class precision/recall, then average *unweighted* — every class counts equally, so rare classes get a voice\n\nChoosing between them is choosing whose experience the metric represents: the average *case* (weighted) or the average *class* (macro). Report both and the reader sees the whole distribution — the bulk and the tail."},{"type":"concept","title":"Always report the baseline","body":"A score means nothing without the number it had to beat. The honest report has two lines: the model's metric and the best trivial alternative's.\n\nFor classification that's the majority-class rate; for regression, predicting the mean — that's literally what R² compares against, and a model with R² = −0.2 is worse than guessing the average every time.\n\nThe habit catches embarrassments automatically: the fraud model at 97% vs 99% baseline, the churn model at 84% vs 82% baseline. Two numbers, one question — *did the model add anything?*"},{"type":"activity","title":"Try it yourself","activity":"neuron-lab"},{"type":"quiz","question":"Your model hits 99% accuracy on a dataset that's 99% negative. What can you safely conclude?","options":["The model is highly effective","It must have a bug","It needs more training data","Almost nothing — it could be predicting 'negative' every time"],"answer":3,"explanation":"With 99% negatives, even a model that never outputs 'positive' scores 99%. Accuracy hides which class the model is failing — you need the confusion matrix to see what's really happening."}],"challenge":[{"question":"A rare-disease screen (prevalence 0.1%) catches 80 of 100 true cases and raises 200 false alarms among 99,900 healthy patients. Accuracy is ~99.8% — yet a critic calls the test bad. What number makes the critic's case?","options":["The 99.8% accuracy itself","The enormous true-negative count","The flagged population: of 280 people marked positive, only 80 were sick — about 29% precision","The dataset size — 100,000 patients is too few"],"answer":2,"explanation":"Accuracy counts the ~99,700 correct negatives as wins and drowns the real story: most flagged patients are false alarms. Precision and recall expose what accuracy hides — how wrong the flags are and how many cases slip through."},{"question":"To 'improve' the fraud metric, a manager instructs the model to flag *fewer* transactions. Accuracy rises from 98.9% to 99.2%. What actually happened?","options":["On a 1%-positive dataset, predicting 'legit' more often mechanically raises accuracy while missing more real fraud","The model got better at catching fraud","Nothing — accuracy is the metric that matters","The test set must have gotten easier"],"answer":0,"explanation":"Under class imbalance, accuracy rewards timidity: every positive prediction risks being wrong, while 'negative' is almost always safe. The metric climbed while the product quietly got worse — the classic accuracy trap."},{"question":"Two classifiers score identical 97% accuracy on the same imbalanced test set. One misses 30 real frauds; the other flags 3,000 innocent customers. What does the shared accuracy tell you?","options":["They're equally good — 97% is 97%","The second model is better because 3,000 > 30","The first model is better because fraud is rare","Almost nothing — identical accuracy can mask completely different failure profiles with wildly different costs"],"answer":3,"explanation":"Accuracy is one weighted average of two very different mistakes and says nothing about the mix. The confusion matrix — TP, FP, FN, TN — is the minimum honest description of what each model is actually doing."}]},{"id":"precision-vs-recall","title":"Precision vs Recall","description":"The tradeoff behind every 'flagged' decision","duration":8,"xp":80,"steps":[{"type":"concept","title":"Two questions, two metrics","body":"**Precision** asks: *of everything I flagged, how much was real?* — `TP / (TP + FP)`. For a spam filter: of the mail sent to the spam folder, how much was actually spam? High precision means few false accusations.\n\n**Recall** asks: *of all the real positives out there, how many did I catch?* — `TP / (TP + FN)`. For a cancer screen: of all actual tumors, how many were found? High recall means few misses.\n\nBoth matter. Almost never at the same time.","callout":{"kind":"analogy","text":"Precision is 'don't cry wolf.' Recall is 'don't miss the wolf.' Every classifier balances on that ridge."}},{"type":"concept","title":"Worked numbers, burned in","body":"A content-moderation model flags 200 posts; 150 are truly violations, so 50 innocents got flagged. Meanwhile 450 real violations went unflagged.\n\n- **Precision** = 150/200 = 75% — of everything flagged, three quarters deserved it\n- **Recall** = 150/600 = 25% — of the 600 real violations out there, we caught a quarter\n\nSame confusion matrix, two questions, two denominators — that's the whole trick. Precision divides by *what you flagged*; recall divides by *what was really out there*. Mixing them up is how teams ship 25%-recall models while quoting '75% accurate moderation.'"},{"type":"quiz","question":"A detector flags 400 emails as spam; 320 are truly spam, and 480 more spam emails sail through to the inbox. Precision and recall?","options":["P=80%, R=80%","P=80%, R=40%","P=40%, R=80%","P=60%, R=80%"],"answer":1,"explanation":"Precision: 320/400 = 80% of flags were right. Recall: 320/(320+480) = 40% of real spam was caught. The denominators differ — flagged set vs. actual spam — which is exactly the asymmetry the two metrics exist to expose."},{"type":"concept","title":"The tradeoff, and who pays for it","body":"Flag more things and recall climbs — you catch more real positives — but precision falls, because you sweep up innocents too. Flag fewer and precision climbs while recall falls. Short of a perfectly separable problem, you can't max both.\n\nSo pick the error that hurts less:\n\n- **Spam filter**: favor *precision*. A missed spam is annoying; a real email lost to the spam folder is a disaster.\n- **Cancer screening**: favor *recall*. A false alarm costs a follow-up scan; a missed tumor costs far more.\n- **Fraud detection**: balance both — every false positive is a customer whose card got declined at the register.","callout":{"kind":"insight","text":"Choosing between precision and recall is choosing which mistake you can afford. That's a product decision dressed as a math problem."}},{"type":"concept","title":"F1: one number, one compromise","body":"When a leaderboard demands a single score, **F1** — the harmonic mean of precision and recall, `2PR/(P+R)` — is the usual answer. For the moderation model above: `2·0.75·0.25/(0.75+0.25) = 0.375`.\n\nHarmonic, not arithmetic, is the point: the mean is dragged toward the *smaller* input, so a model can't inflate F1 by maxing one metric and tanking the other. P=95%, R=5% gives F1 ≈ 0.09 — the formula refuses to reward the one-sided cheat.\n\nBut F1 carries its own bias: it prices precision and recall equally. When they aren't equal — cancer screen vs. spam folder — **Fβ** weights the blend (β=2 counts recall twice as much). A single number always embeds an opinion about what matters.","callout":{"kind":"warning","text":"F1 treats the two errors as equal-cost — a strong, often wrong, assumption. Before adopting any single metric, ask what ratio of harm it assumes between a miss and a false alarm."}},{"type":"concept","title":"Prevalence moves precision","body":"Here's a fact that breaks intuition in production: precision depends on how common the positive class *is*, not just how good the model is.\n\nSame test, same 95% recall, same 2% false-positive rate — deployed where prevalence is 50%, of every 100 flagged ~98 are real: precision ≈ 98%. Deployed where prevalence is 1%, of every 100 flagged only ~33 are real: precision ≈ 33%. The model didn't change; the base rate did.\n\nThis is why a diagnostic test brilliant in trials collapses as a population screen — and why precision numbers quoted without prevalence are meaningless. Recall is a property of the model; precision is a property of the model *in a population*.","callout":{"kind":"insight","text":"The base-rate trap: as positives get rarer, even tiny false-positive rates flood your flags with innocents. When someone quotes precision, the only honest follow-up is 'at what prevalence?'"}},{"type":"quiz","question":"A fraud model has 90% recall and a 1% false-positive rate. Fraud prevalence drops from 5% to 0.5%. Precision will:","options":["Stay the same — it's a model property","Rise — rarer fraud is easier to catch","Become uncomputable","Fall sharply — the same FP rate applied to a much larger innocent pool floods the flags"],"answer":3,"explanation":"With fraud rarer, the 1% false-positive rate applies to a far larger legit population — false alarms grow relative to real catches. Precision is a function of base rate; it's why screening rare diseases is precision's nightmare."},{"type":"concept","title":"Put prices on the errors","body":"Metrics compress the confusion matrix into a number — but a cost matrix compresses it *correctly for your problem*.\n\nAssign each cell a price: a missed fraud costs the stolen amount (~$500), a false alarm costs an annoyed customer and a support call (~$25). Then expected cost per transaction = `FN·500 + FP·25`, and the best model is the cheapest one — a comparison no single accuracy, F1, or AUC makes for you.\n\nThis reframing settles arguments that metrics can't: 'should we flag more?' becomes 'does the marginal catch save more than the marginal alarm costs?' Once errors are priced, the metric stops being a debate and becomes arithmetic."},{"type":"activity","title":"Try it yourself","activity":"lr-lab"},{"type":"quiz","question":"For a cancer-screening model, which metric should you optimize hardest?","options":["Accuracy — overall correctness is the goal","Precision — avoid false alarms at all costs","Recall — miss as few real cancers as possible","Speed — faster screening helps more patients"],"answer":2,"explanation":"A false negative — cancer the model misses — is the catastrophic outcome, and recall directly measures missed positives. A false positive costs a follow-up scan: expensive, but recoverable."}],"challenge":[{"question":"A model flags 500 posts as hate speech — 400 really are, 100 are mistakes. Meanwhile 300 genuinely hateful posts went unflagged. Precision and recall are:","options":["Precision 80%, recall ~57%","Precision ~57%, recall 80%","Precision 90%, recall 80%","Both exactly 80%"],"answer":0,"explanation":"Precision asks 'of everything flagged, how much was real': 400/500 = 80%. Recall asks 'of all real positives, how many did we catch': 400/700 ≈ 57%. The denominators differ — flagged set vs. actual positives."},{"question":"An airport security scanner flags bags for manual search. Missing a dangerous item is catastrophic; an extra bag search is a mild inconvenience. Which error should the system be tuned to minimize?","options":["False positives — passenger trust matters most","False negatives — recall must stay near 1 even if precision drops and queues grow","Both equally, always","Neither — maximize raw accuracy"],"answer":1,"explanation":"When a miss costs catastrophically more than a false alarm, you buy recall with precision — flag aggressively and let humans sort it out. The precision/recall dial is set by the price of each mistake, not by math."},{"question":"A platform auto-bans accounts flagged as bots, and a wrongful ban loses a real customer permanently. Which tradeoff should the classifier favor?","options":["High precision — only ban when nearly certain, accepting that some bots slip through","High recall — catch every bot no matter what","High accuracy — it balances both automatically","Low recall and low precision together"],"answer":0,"explanation":"The irreversible action falls on the flagged: every false positive is a real customer destroyed. Precision — 'of those we punished, how many deserved it' — is the metric that prices that mistake."},{"question":"A colleague 'solves' recall by flagging literally every transaction as fraud. Recall is a perfect 1.0. What's the catch?","options":["There is no catch — recall 1.0 is optimal","Accuracy hits 1.0 too","Precision collapses toward the base rate — thousands of innocents got flagged to catch every fraud","The model stopped being a classifier"],"answer":2,"explanation":"Recall alone is trivially gameable — flag everything and you miss nothing. Precision is what pays the bill for that strategy, which is exactly why the two metrics are always reported as a pair."}]},{"id":"thresholds-and-roc","title":"Thresholds, ROC & AUC","description":"Moving the decision line — and grading the whole curve","duration":8,"xp":80,"steps":[{"type":"concept","title":"Models output scores, not verdicts","body":"A spam classifier doesn't output 'spam' — it outputs something like *0.73: probably spam*. A **threshold** turns that score into a decision: 0.73 ≥ 0.5 → spam folder.\n\nMove the line and the product changes:\n\n- **Lower the threshold** → more spam caught (recall up), more real mail flagged (precision down)\n- **Raise it** → a cleaner spam folder, but more junk reaching the inbox\n\nThe model didn't change. The standard of proof did.","callout":{"kind":"insight","text":"The model proposes; the threshold decides. One model plus ten thresholds is ten different products."}},{"type":"concept","title":"Same model, three thresholds","body":"One spam model, one test set, three thresholds — three different products:\n\n- **t = 0.9**: flags only near-certain spam — 60% of spam caught, flags 99% accurate. Precision 0.99, recall 0.60\n- **t = 0.5**: the default — 85% caught, 95% of flags correct. Precision 0.95, recall 0.85\n- **t = 0.2**: nearly everything suspicious filtered — 98% caught, but a quarter of flags are real mail. Precision 0.75, recall 0.98\n\nNothing was retrained; a dial moved. The first lesson of thresholds: *the model is a score function, and the product is a score function plus a cut.* Evaluate the pair, not the model alone."},{"type":"quiz","question":"A medical screen moves its threshold so only very high scores count as positive. The effect on the confusion matrix:","options":["More FP, fewer FN","More FN, fewer FP","Both error types improve","TP rises, everything else falls"],"answer":1,"explanation":"A stricter bar means fewer positive calls: fewer healthy people get flagged (FP down) but more sick people are missed (FN up). Every threshold move buys one error type by selling the other."},{"type":"concept","title":"ROC and AUC: grade every threshold at once","body":"The **ROC curve** sweeps the threshold from strict to lenient and, at every point, plots how many real positives you catch (true positive rate) against how many innocents you flag (false positive rate).\n\n**AUC** — the area under that curve — compresses the whole sweep into one number. Its neat interpretation: the probability that the model scores a random positive higher than a random negative. AUC 0.5 is a coin flip; 1.0 is flawless.","callout":{"kind":"analogy","text":"If precision and recall are snapshots taken at one threshold, the ROC curve is the video of all of them."}},{"type":"concept","title":"Where ROC flatters: the PR curve","body":"ROC has a blind spot, and it's the same one accuracy has: the x-axis is the false-positive *rate* — FPs divided by a huge pool of negatives. On a 1%-positive dataset you can look 'free' on ROC: flagging 1% of 99,000 innocents earns a tidy x of 0.01, while those 990 false alarms utterly destroy precision.\n\nThe **precision–recall curve** plots the metrics that ignore the giant TN pool entirely, exposing exactly what rare-class practitioners care about: of my flags, how many are real, at every threshold.\n\nRule of thumb: balanced classes → ROC is fine. Rare positives → the PR curve and its area (**AUPRC**) tell the truth ROC flatters away.","callout":{"kind":"warning","text":"An AUC of 0.95 on 0.1% positives can coexist with garbage precision at every usable threshold. On rare-event problems, read the PR curve — or prepare to explain the discrepancy to whoever triages the flags."}},{"type":"visualization","title":"Every boundary is a threshold","component":"decision-boundary","caption":"A decision boundary is a threshold drawn in feature space — one side scores 'yes,' the other 'no.' Each boundary trades one kind of error for another."},{"type":"concept","title":"A score isn't a probability (yet)","body":"A model output of 0.73 feels like '73% chance' — but for many models it isn't. Scores from SVMs, boosted trees, and neural nets are *rankings*: higher means likelier, without promising that 73% of '0.73' predictions come true.\n\n**Calibration** is the property that 0.73 should mean 'truly positive about 73% of the time.' When decisions price risk — lending, insurance, medicine — you check it with a reliability curve and fix it with a calibration layer (Platt scaling, isotonic regression) fit on held-out data.\n\nA model can rank beautifully and still lie about odds. Ranking quality and probability honesty are separate virtues, separately earned.","callout":{"kind":"insight","text":"Ranking answers 'who's riskier than whom.' Calibration answers 'how risky, in dollars.' Ordering loans needs the first; pricing them needs the second."}},{"type":"quiz","question":"A lender needs 'probability of default' for pricing, but the model only ranks applicants by risk score. What's missing?","options":["Nothing — a score is a probability","A bigger training set","A harder threshold","Calibration — the mapping from score to honest probability, fit on held-out data (Platt scaling / isotonic regression)"],"answer":3,"explanation":"Ranking ≠ probability: a model can order risk perfectly while its scores mean nothing as odds. Calibration fits the score-to-probability mapping on held-out labels — mandatory whenever decisions are priced on the number."},{"type":"concept","title":"Picking the operating point","body":"Three defensible ways to set the cut:\n\n- **Cost-optimal**: minimize `FN·cost_FN + FP·cost_FP` over candidate thresholds — the choice that prices your actual mistakes\n- **Constraint-driven**: 'at least 95% recall, whatever precision results' — common in screening, where the miss is catastrophic\n- **Youden's J**: the point maximizing `TPR − FPR` — the geometric 'best corner' of ROC, a reasonable default when costs are genuinely unknown\n\nWhichever rule you use, the discipline is the same: choose the threshold on *validation* data, then evaluate the final configuration — model plus cut — once on test. A threshold chosen on test is test-set tuning in a trench coat."},{"type":"activity","title":"Try it yourself","activity":"threshold-lab"},{"type":"quiz","question":"You lower a spam filter's threshold from 0.8 to 0.3. The most likely result?","options":["Higher precision, lower recall","Higher recall, lower precision","Both precision and recall improve","Both precision and recall get worse"],"answer":1,"explanation":"A lower bar for 'spam' catches more actual spam — recall rises — but sweeps more legitimate mail into the folder, so precision falls. Same model, different tradeoff."}],"challenge":[{"question":"After complaints about spam reaching inboxes, your team raises the filter threshold from 0.5 to 0.9. Predict the result.","options":["The spam folder gets cleaner (precision up) but borderline spam sails through to the inbox (recall down)","Inbox spam falls and nothing else changes","Both precision and recall improve","The model must be retrained for the new threshold"],"answer":0,"explanation":"A higher bar for 'spam' means only near-certain junk gets filtered — the folder gets cleaner while more borderline spam slips by. Same model, stricter standard of proof, different tradeoff."},{"question":"AUC = 0.9 means:","options":["The model is right 90% of the time","90% of predictions exceed the threshold","There's a 90% chance a random positive scores above a random negative — ranking quality across every threshold","Precision is 0.9 at all thresholds"],"answer":2,"explanation":"AUC integrates the ROC curve: pick a random positive and a random negative, and 0.9 is the probability the model ranks the positive higher. It says nothing about accuracy at any single operating point."},{"question":"A fraud model shows AUC 0.97, yet at the deployed threshold it catches almost no fraud. How can both be true?","options":["AUC is broken — report accuracy instead","The dataset is too small for AUC to mean anything","The model needs more fraud features","The threshold was never tuned — AUC measures ranking quality across all thresholds, not performance at the one you shipped"],"answer":3,"explanation":"A model can rank positives above negatives beautifully yet flag almost nothing if the decision line sits too high. AUC grades the score function; the threshold decides what the product actually does."},{"question":"Who should set the operating threshold on a medical screening model?","options":["The optimizer — it picks automatically during training","Always 0.5 — the mathematical default","Whoever can price the mistakes — it's a clinical/business decision about the cost of a miss versus a false alarm","Whatever threshold maximizes accuracy on the test set"],"answer":2,"explanation":"The threshold converts a score into an action, and the right conversion depends on real-world costs no training loop can see. Defaulting to 0.5 — or to whatever maximizes a convenient metric — is a decision too, just an unexamined one."}]}]},{"id":"generalization","title":"Generalization","description":"Learning patterns that survive contact with new data","lessons":[{"id":"train-validation-test","title":"Train/Validation/Test Done Right","description":"Why honest evaluation needs three splits, not two","duration":7,"xp":70,"steps":[{"type":"concept","title":"Three splits, three jobs","body":"You've met the test set — but honest evaluation actually needs three partitions, each with a single job:\n\n- **Training set**: the data the model learns from\n- **Validation set**: the data *you* learn from — every choice of learning rate, architecture, or feature set is judged here\n- **Test set**: the untouched final exam, used once at the end\n\nWhy the middle split? Because tuning on the test set is still fitting to it — through your decisions rather than the model's weights.","callout":{"kind":"analogy","text":"Training is practice problems. Validation is the mock exam that tells you which study strategy works. The test is the real exam — and you only get to take it once."}},{"type":"concept","title":"The workflow, numbered","body":"Concrete: 100,000 rows → 60k train / 20k validation / 20k test. The discipline in order:\n\n1. Train candidate models on the 60k only\n2. Compare them on the 20k validation — every architecture, feature set, and threshold decision happens here\n3. Freeze everything: preprocessing statistics, chosen hyperparameters, the threshold\n4. Evaluate once on the 20k test — report that number, unchanged\n\nTwo rules the pipeline enforces: nothing is *fit* outside the training split — scalers, encoders, feature selection included — and the test set is consumed exactly once. If the test score disappoints, the honest response isn't to peek again: it's to accept it, or start the project over with fresh test data."},{"type":"quiz","question":"You fit feature selection on train+validation 'for stability,' then evaluate on test. A reviewer objects. She's right because:","options":["Any selection made with validation knowledge shapes what the validation score meant — every fit belongs inside the training data it describes","Feature selection isn't a learned step","Validation data should never be used for anything","Feature selection must use the test set"],"answer":0,"explanation":"Anything that learns from data — scalers, feature selectors, encoders — must be fit inside the training portion of whatever evaluation you're running. Fit it on data your metrics depend on and the measurement is already spent."},{"type":"concept","title":"The leak that ruins everything","body":"**Data leakage** is any path by which test-time information sneaks into training — the most common silent killer of real-world ML:\n\n- The same patient appears in both train and test scans — the model memorizes *them*, not the disease\n- A feature secretly encodes the label — like a `diagnosis_date` column used to predict diagnosis\n- Temporal leakage: the model trains on next week's data to predict last week's\n\nLeakage produces beautiful metrics and broken products.","callout":{"kind":"warning","text":"Tune on the test set even once — 'let's just check' — and it stops being a test set. It becomes a validation set with good PR."}},{"type":"concept","title":"The four species of leak","body":"Leakage wears four costumes:\n\n- **Feature leakage**: a column encodes the answer — `days_since_last_chemo` for predicting diagnosis\n- **Row leakage**: the same entity on both sides — a patient's scans in train *and* test\n- **Preprocessing leakage**: statistics fit on all rows — a scaler whose minimum saw the test set\n- **Temporal leakage**: training rows from after the prediction point — next quarter's data predicting last month's\n\nAll four produce the same pathology: metrics that describe a world where the future is visible. Detection recipe: for every number the model consumes, ask 'was this knowable, at this timestamp, for this entity?' If not — leak.","callout":{"kind":"warning","text":"Leakage is why 'it worked in the notebook' is a running joke. The notebook has access to everything; production only has the past."}},{"type":"concept","title":"Split like you mean it","body":"How you split matters as much as whether you split:\n\n- **Shuffle first** — data often arrives ordered: all positives, then all negatives\n- **Stratify** — keep the class ratio consistent across splits, or your rare class may vanish from one\n- **Group together** — every row from the same patient, user, or device stays in the same split\n- **Respect time** — for forecasting, the test set must come *after* the training set chronologically\n\nThe goal: a test set that honestly simulates the future — data you've never seen, from the world you'll actually deploy in."},{"type":"concept","title":"Small data: rotate the test set","body":"Three splits are affordable at 100k rows. At 2,000, holding out 20% twice costs a third of your training data and gives you a single, noisy evaluation.\n\n**k-fold cross-validation** answers this: split into k blocks (typically 5 or 10), train on k−1, evaluate on the held-out block, rotate until every block has been the test set once. Average the k scores — each row served as unseen data exactly once, and the estimate is far stabler than any single split.\n\nThe rules persist: preprocessing fits *inside* each fold's training block, groups stay whole, and time-ordered data needs the rolling variant — CV done wrong leaks exactly like a bad split."},{"type":"quiz","question":"On a 1,500-row dataset, why is 10-fold CV better than one 80/20 split?","options":["It's faster","It prevents overfitting","It creates more training data","Every row gets to be test data once — the average over 10 rotations is far more stable than a single lucky draw"],"answer":3,"explanation":"A single split's estimate rides on which 300 rows happened to land in test. Rotating averages out that luck and lets you train on 90% of the data each fold — more evaluation *and* more training data from the same 1,500 rows."},{"type":"concept","title":"The reuse budget","body":"Validation sets spend honesty too — just slower. Every kept decision is a small bet on the validation split; after hundreds of experiments, you've tuned to its particular noise. The score it reports is now optimistic by exactly the selection pressure you applied.\n\nPractitioners manage it as a budget:\n\n- **Track experiment count** — after ~100+ validation-guided decisions, distrust the gap between validation and test\n- **Refresh splits periodically** — a new validation draw re-reads whether you've been chasing signal or noise\n- **Hold the test set in escrow** — one look, at the end, before launch\n\nThe deepest truth of the three-split system: it isn't about data hygiene. It's about honestly answering 'how many times did I get to look?' — because every look costs accuracy you never had."},{"type":"activity","title":"Try it yourself","activity":"neuron-lab"},{"type":"quiz","question":"You train 20 model variants, evaluate all of them on the test set, and ship the best scorer. What went wrong?","options":["Nothing — that's what the test set is for","You tuned on the test set — it no longer measures generalization","20 variants is too few to be reliable","You should have used accuracy instead"],"answer":1,"explanation":"Selecting the best test score is optimization against the test set — it inflates your estimate of real-world performance. Model selection belongs on the validation set; the test set is for one final, honest check."}],"challenge":[{"question":"You scale features using statistics from the full dataset, *then* split into train/validation/test. A reviewer flags leakage. Is she right?","options":["No — scaling is just arithmetic, not learning","No — leakage only ever involves labels","Yes — but only if the test set is large","Yes — the min/max/mean absorbed test values into training preprocessing; fit transforms on train only, then apply"],"answer":3,"explanation":"Leakage isn't only about labels — any statistic computed on test data shapes how the training data is represented. Fit preprocessing inside the training split and freeze it for everything downstream."},{"question":"Predicting next month's churn, you randomly shuffle dated rows into train and test. Validation looks great; production fails immediately. The leak?","options":["Shuffling is always wrong for any dataset","The validation set was too small","The model trained on 'future' months to predict 'past' ones — for temporal data the test set must come after training chronologically","Churn is inherently unpredictable"],"answer":2,"explanation":"Shuffled splits let the model preview the future — next quarter's level, trends, and shocks — to 'predict' the past. Temporal problems need temporal splits: train on the past, test on what came after."},{"question":"Your team iterates on the validation set for months — hundreds of tweaks, keeping each winner. Validation accuracy plateaus at 91%. What danger now lurks?","options":["You've slowly overfit the validation set itself — enough selection pressure makes its score optimistic; only the untouched test set gives an honest final read","None — that's exactly what validation is for","The test set is definitely 91% too","Validation sets expire after fifty iterations"],"answer":0,"explanation":"Every kept decision is a small bet on the validation set; enough bets and the model is tuned to its noise, not just its signal. That's why the test set stays locked until the end — it's the one number never optimized against."},{"question":"The same `user_id` appears in both train and test rows — different sessions, same person. The model does well on test but flops on genuinely new users. Why?","options":["User IDs should never be a feature","The model learned individual users' habits, not general behavior — group all rows per user into one split so test users are truly unseen","New users are inherently unpredictable","More training data would fix it"],"answer":1,"explanation":"Random row splits leak identity: the model memorizes 'how user 42 behaves' rather than 'how users behave.' Splitting by entity — patient, user, device — makes the test set simulate deployment, where the users are new."}]},{"id":"regularization","title":"Regularization: Simplicity That Generalizes","description":"L1, L2, and early stopping — pressure toward simpler models","duration":9,"xp":85,"steps":[{"type":"concept","title":"Simpler generalizes","body":"An overfit model is a student who memorized the answer key — perfect on practice, lost on the real exam. **Regularization** is deliberate friction during training that pushes toward simpler explanations, because simple explanations travel better to new data.\n\nThe mechanism: add a complexity penalty to the loss, so the model only keeps a complicated pattern when it truly earns its keep.","callout":{"kind":"insight","text":"Regularization isn't about the training set at all. It's an insurance policy — you pay a little training accuracy and collect on unseen data."}},{"type":"concept","title":"The penalty term, in numbers","body":"Regularized loss is two terms: `loss = error + λ·(sum of |w| or w²)`. The λ (lambda) sets the exchange rate between fit and simplicity.\n\nConcrete with L2: model A fits perfectly (error 0) with giant weights summing to Σw² = 100; model B fits almost as well (error 2) with Σw² = 4. At λ = 0.1: A costs `0 + 10 = 10`, B costs `2 + 0.4 = 2.4` — B wins by a mile. At λ = 0, A wins; at λ = 10, the model may prefer predicting the mean to paying for any weights at all.\n\nThat's the whole mechanism in one line: λ decides how much a unit of training error buys in complexity. Zero λ and you get memorization; huge λ and you get a model too poor to say anything."},{"type":"concept","title":"L1 and L2: two flavors of penalty","body":"Both punish large weights, but differently:\n\n- **L2 (weight decay)**: penalizes the *square* of each weight — prefers many small weights over a few big ones, producing smooth, diffuse models. The default choice.\n- **L1**: penalizes the *absolute* value of each weight — pushes useless weights all the way to **zero**, doing feature selection for you.\n\nReach for L1 when you suspect most features are noise; L2 when you want every feature to contribute a little.","callout":{"kind":"analogy","text":"L2 taxes big weights so they all stay modest. L1 taxes weights until the useless ones go bankrupt entirely."}},{"type":"quiz","question":"Two models on the same loss: A has error 1 with Σw² = 20; B has error 3 with Σw² = 2. At λ = 0.5 (L2), which does the optimizer prefer?","options":["B — total cost 3+1=4 vs A's 1+10=11","A — lower error always wins","A — penalties don't affect selection","Neither — λ must be tuned first"],"answer":0,"explanation":"L2 total = error + λ·Σw². A: 1 + 0.5·20 = 11. B: 3 + 0.5·2 = 4. The penalty makes B's simplicity worth more than A's two extra points of fit — regularization is arithmetic, not taste."},{"type":"concept","title":"Early stopping: the cheapest regularizer","body":"Training longer isn't always learning more. Past a certain point the model shifts from learning patterns to memorizing noise — training loss keeps falling while validation loss turns upward.\n\n**Early stopping** watches that divergence and halts at the validation minimum. It costs nothing, works everywhere, and doubles as an overfitting alarm.","callout":{"kind":"insight","text":"Every epoch past the validation minimum is a step away from the model you should ship."}},{"type":"visualization","title":"Find the pivot point","component":"overfitting","caption":"Push complexity or training time and watch validation error turn upward while training error keeps falling. Early stopping freezes the model at the bottom of that valley."},{"type":"concept","title":"The rest of the regularization zoo","body":"Weight penalties are the famous ones; the zoo is bigger:\n\n- **Dropout**: randomly zero a fraction of activations each step — the network can't lean on any single feature pathway, so it builds redundant ones\n- **Data augmentation**: rotate images, paraphrase text, jitter values — teaching invariances with synthetic variety is regularization through extra data\n- **More real data**: the most reliable regularizer of all — 10× the rows is usually worth more than any penalty schedule\n- **Smaller capacity**: fewer parameters is regularization applied before training starts\n\nSame philosophy throughout: make the easy-but-wrong solutions expensive, so the model only finds patterns robust enough to survive the friction."},{"type":"concept","title":"Dialing in the penalty","body":"λ is a hyperparameter, tuned on validation like any other — but the search has its own folklore:\n\n- **Search in logs**: λ lives across orders of magnitude — try `10⁻⁴, 10⁻³, …, 10¹` before interpolating; linear grids waste evaluations on a logarithmic landscape\n- **Read the symptoms**: train and validation error *both* high → λ too strong (underfit); big gap between them → λ too weak (overfit)\n- **Weight decay is L2's modern name** — same math applied inside the optimizer; `1e-2` to `1e-4` is the usual deep-net starting band\n\nThe dial's direction is memorable: λ controls *how much* the model pays for complexity — not whether it can afford any."},{"type":"quiz","question":"Training error and validation error are both high — the model can't even fit the data it sees. The regularization prescription?","options":["Increase λ — more regularization needed","Add dropout","Decrease λ — the penalty is too strong; the model can't afford the weights it needs","Collect noisier data"],"answer":2,"explanation":"Both errors high = underfitting — the penalty is choking real signal along with noise. Regularization is a dial, and too far in either direction fails: back λ off until validation error bottoms out."},{"type":"activity","title":"Try it yourself","activity":"lr-lab"},{"type":"quiz","question":"You want the model to discard useless features entirely — drive their weights to exactly zero. Which regularizer?","options":["L2 regularization","L1 regularization","Early stopping","A larger test set"],"answer":1,"explanation":"L1's absolute-value penalty pushes small, useless weights all the way to zero — effectively deleting those features. L2 shrinks weights but rarely reaches zero; early stopping controls training time, not which features survive."}],"challenge":[{"question":"After adding a strong L1 penalty, validation error gets *worse* — and half the features now have exactly-zero weights. What probably happened?","options":["L1 always hurts — switch to L2","The features were normalized incorrectly","L1 doesn't actually touch weights","The penalty is too strong — it deleted real features along with noise, pushing the model into underfitting"],"answer":3,"explanation":"Regularization is a dial, not a switch: crank the penalty high enough and the model can't afford weights it genuinely needs. The cure is the same as the disease — back the coefficient down until validation error bottoms out."},{"question":"Validation loss bottoms at epoch 30, then climbs steadily while training loss keeps falling. You let it run to epoch 500 'for completeness.' What did you ship?","options":["The best model — more training is more learning","A model 470 epochs past its best — the extra training was spent memorizing noise, and early stopping existed to freeze it at that valley","A properly regularized model","A model now immune to overfitting"],"answer":1,"explanation":"Past the validation minimum the model shifts from learning patterns to memorizing the training set. Early stopping is the cheapest regularizer precisely because it catches that pivot for free."},{"question":"You suspect 90% of your 5,000 features are pure noise and want the survivors to be the ones that matter. Which regularizer fits — and why?","options":["L1 — its absolute-value penalty drives useless weights to exactly zero, performing feature selection for you","L2 — it spreads weight smoothly across all features","Early stopping — it controls training time","Dropout — it randomly removes features"],"answer":0,"explanation":"L1's penalty pushes small weights all the way to zero rather than merely shrinking them — effectively deleting noise features and keeping the ones that earn their keep. L2 prefers many small contributors instead."},{"question":"A regularized model scores slightly *worse* on the training set than an unregularized one, and your manager asks why you'd accept that. The honest answer?","options":["Regularization is a bug we haven't fixed yet","The regularized model is simpler, which is automatically better","Training accuracy isn't the goal — we trade a little memorization for patterns that survive unseen data","We shouldn't — revert to the unregularized model"],"answer":2,"explanation":"Regularization is deliberate friction: you pay a little training accuracy as an insurance premium and collect on test data. Perfect scores on seen data are easy; generalization is the actual product."}]}]}]},"module":"$22:props:children:props:track:modules:1","lesson":"$22:props:children:props:track:modules:1:lessons:0","prev":{"href":"/tracks/ml-foundations/garbage-in","title":"Why Data Quality Wins"},"next":{"href":"/tracks/ml-foundations/gradient-descent-deep","title":"Gradient Descent, Properly"},"initialStep":0}]}] 27:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]] 2b:I[27201,["/_next/static/chunks/43v7y6x3eg2ur.js","/_next/static/chunks/12xh8d8esig5n.js","/_next/static/chunks/18-gn3bjo15zd.js","/_next/static/chunks/1msdpso3qlrt6.js","/_next/static/chunks/3_fxm8bhygrh7.js","/_next/static/chunks/3j9ojc-ugnhuo.js","/_next/static/chunks/1tyt04182z3kp.js"],"IconMark"] 25:null 29:[["$","title","0",{"children":"Drawing the Line — Percept — Percept"}],["$","meta","1",{"name":"description","content":"Classification as carving up space"}],["$","link","2",{"rel":"manifest","href":"/manifest.webmanifest","crossOrigin":"$undefined"}],["$","meta","3",{"property":"og:title","content":"Percept — Learn AI Visually"}],["$","meta","4",{"property":"og:description","content":"Interactive lessons, a real AI tutor named Nova, and verifiable certificates — AI literacy for teens to adults."}],["$","meta","5",{"property":"og:url","content":"https://percept-779.netlify.app"}],["$","meta","6",{"property":"og:site_name","content":"Percept"}],["$","meta","7",{"property":"og:type","content":"website"}],["$","meta","8",{"name":"twitter:card","content":"summary"}],["$","meta","9",{"name":"twitter:title","content":"Percept — Learn AI Visually"}],["$","meta","10",{"name":"twitter:description","content":"Interactive lessons, a real AI tutor named Nova, and verifiable certificates — AI literacy for teens to adults."}],["$","link","11",{"rel":"icon","href":"/icon.svg?icon.3dtn6467a47z6.svg","sizes":"any","type":"image/svg+xml"}],["$","link","12",{"rel":"apple-touch-icon","href":"/apple-icon.png?apple-icon.307dre0hc2gw1.png","sizes":"180x180","type":"image/png"}],["$","$L2b","13",{}]]