{"id":10168,"date":"2026-08-31T05:40:55","date_gmt":"2026-08-31T03:40:55","guid":{"rendered":"https:\/\/qdata.pl\/blog\/from-notebook-to-production-without-magic-mlops\/"},"modified":"2026-08-31T07:47:11","modified_gmt":"2026-08-31T05:47:11","slug":"from-notebook-to-production-without-magic-mlops","status":"publish","type":"post","link":"https:\/\/qdata.pl\/pl\/blog\/from-notebook-to-production-without-magic-mlops\/","title":{"rendered":"Od notebooka do produkcji bez \u201emagicznego\u201d MLOps"},"content":{"rendered":"<div class=\"qdata-blog-tldr\">\n<h3>TL;DR<\/h3>\n<ul>\n<li>If you cannot reproduce last month&#8217;s model from code + data snapshot, you are not in production \u2014 you are in demo.<\/li>\n<li>Start with one decision, one metric, one rollback path \u2014 not a platform RFP.<\/li>\n<li>Feature stores help when teams share features; they hurt when built before a second model exists.<\/li>\n<li>Monitoring = data quality + prediction behaviour + business KPI \u2014 not only uptime.<\/li>\n<\/ul>\n<\/div>\n<p>Teams often arrive with a notebook that beats the baseline on a held-out slice and a slide that says &#8220;MLOps next quarter.&#8221; The gap between that notebook and a system auditors and operators can trust is where most AI programmes stall. The fix is not a mythical mythical MLOps platform sold with a marketing slide \u2014 it is a <strong>minimum chain of evidence<\/strong> from raw data to scored output, owned by people who will be on call when the model misbehaves on a Monday morning.<\/p>\n<p>We have seen the same pattern in retail demand forecasting, industrial defect detection and credit scoring: a brilliant offline metric, then six months of platform evaluation while production still runs on a cron job and a pickle file on a shared drive. The organisations that ship fastest start narrow. They pick one decision the business already makes manually, one metric that matters to that decision, and one rollback path when the model is wrong. Everything else is sequenced after proof, not before.<\/p>\n<h2>The minimum production chain<\/h2>\n<p>Production ML rests on five links. First, a <strong>data contract<\/strong>: schema, freshness SLA, PII rules, named owner and escalation when upstream feeds slip. Without a contract, &#8220;the data team will fix it&#8221; becomes the incident runbook. Second, a <strong>versioned training set<\/strong> \u2014 an immutable snapshot ID referenced in every model card and deployment record. If you cannot point to the exact rows that trained the model scoring today, you cannot explain a bad Tuesday.<\/p>\n<p>Third, a <strong>Rejestr modeli, wersjonowanie i powtarzalne pipeline treningowe.<\/strong>: container or locked environment, random seed, git SHA, dependency lockfile. Fourth, a <strong>model registry entry<\/strong> with metrics, known limitations, approver name and the artefact promoted to serving. Fifth, <strong>serving with observability<\/strong>: latency, error rate, input distribution, and a feedback loop when labels arrive late. Skip any link and you pay later \u2014 usually during an incident when no one knows which data trained the model currently affecting customers.<\/p>\n<p>A logistics client shipped with this chain in eleven weeks: nightly features in Parquet, training in a scheduled pipeline, promotion gated on hold-out performance and schema checks, serving behind an API with dashboards for input drift. No feature store, no Kubernetes for training. The model was boring; the business trusted it because operators could answer basic forensic questions.<\/p>\n<h2>What to postpone on purpose<\/h2>\n<p>Full feature stores, real-time streaming pipelines and AutoML marketplaces can wait. Build them when you have <em>two or more models<\/em> genuinely reusing features, or sub-minute latency requirements with a measured cost of batch scoring that exceeds the engineering investment. Until then, a well-structured batch pipeline with nightly features and explicit promotion gates is often more reliable \u2014 and far easier to explain to risk committees who ask &#8220;what happens if this model is wrong?&#8221;<\/p>\n<p>We counsel teams to write a <strong>deferral list<\/strong> with triggers: &#8220;feature store when model B shares more than thirty percent of features with model A&#8221; or &#8220;streaming when p95 batch latency blocks revenue.&#8221; That list prevents platform tourism \u2014 six months evaluating vendors while nothing reaches production \u2014 and keeps architects honest about reuse that does not yet exist.<\/p>\n<h2>Governance that engineers will not hate<\/h2>\n<p>Model cards do not need forty pages. One page is enough: intended use, out-of-scope uses, training data summary, fairness and limitation notes, owner, rollback procedure. Tie promotion to automated checks \u2014 schema validation, performance floor on hold-out, bias thresholds where applicable \u2014 plus a human sign-off for production namespaces. Engineers accept governance when it blocks bad deploys automatically instead of adding meetings that review what CI could have caught.<\/p>\n<p>Governance also means <strong>who can press promote<\/strong>. Separation between trainer and approver mirrors production change control. A credit scoring team adopted this after a misconfigured threshold reached production because the same person trained, evaluated and deployed during a deadline crunch. The rollback took longer than the fix because nobody else had context.<\/p>\n<h2>Drift before users notice<\/h2>\n<p>Monitoring wej\u015b\u0107, wyj\u015b\u0107 i proste kontrole jako\u015bci danych <strong>covariate shift<\/strong> on top inputs and <strong>outcome delay<\/strong> where labels arrive late. Alert on distribution change even when accuracy looks stable \u2014 stale accuracy is a common trap when the world changed three weeks ago but labels lag. A retailer continued trusting a demand model through a product mix shift because weekly accuracy on old SKUs looked fine; overstocks appeared in categories the model had never seen at current volumes.<\/p>\n<p>Pair technical drift signals with <strong>business KPIs<\/strong>: return rate, manual override rate, margin impact. When operators override the model more often, that is often a drift signal faster than any statistical test. Instrument overrides; they are free labels about model trust.<\/p>\n<h2>Scenario: fraud scoring vs predictive maintenance<\/h2>\n<p>Two models, same company, different maturity needs. Fraud scoring demands low latency, explainability for investigators and immediate rollback \u2014 the minimum chain includes shadow mode before full promotion and a kill switch wired to a feature flag. Predictive maintenance on batch telemetry tolerates nightly scoring, emphasises data contract with OT teams and documents that missed alerts have safety implications reviewed with operations.<\/p>\n<p>Trying to run both through one generic &#8220;AI platform&#8221; RFP delayed both. Sequencing fraud first \u2014 higher regulatory visibility \u2014 built organisational muscle for registry, monitoring and access control that maintenance inherited six months later. One platform team, two staged deliveries, zero magic.<\/p>\n<h2>What to do next<\/h2>\n<p>Pick one model that affects a real decision this quarter. Write the data contract, snapshot last month&#8217;s training data, containerise training, register the artefact and add three monitoring charts: latency, error rate, top-feature distribution. If you cannot complete that chain, pause the platform RFP. Our <a href=\"\/pl\/service\/data-science-models\/\">Modele Data Science<\/a> practice helps teams ship the minimum chain first, then grow platform capabilities when reuse justifies them \u2014 not when a vendor brochure says so.<\/p>","protected":false},"excerpt":{"rendered":"<p><span data-no-translation>ML w produkcji to nie wi\u0119kszy GPU, tylko wersjonowane dane, powtarzalny trening, kontrolowany deploy i monitoring dryfu \u2014 zaczynaj\u0105c od jednej decyzji, jednej metryki i jednej \u015bcie\u017cki rollback.<\/span><\/p>","protected":false},"author":1,"featured_media":10129,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[62],"tags":[],"class_list":["post-10168","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-ai"],"_links":{"self":[{"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/posts\/10168","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/comments?post=10168"}],"version-history":[{"count":2,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/posts\/10168\/revisions"}],"predecessor-version":[{"id":10178,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/posts\/10168\/revisions\/10178"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/media\/10129"}],"wp:attachment":[{"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/media?parent=10168"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/categories?post=10168"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qdata.pl\/pl\/wp-json\/wp\/v2\/tags?post=10168"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}