<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Feature-Engineering on Varchaleswari Ganugapati</title><link>https://varchaleswariganugapati.com/tags/feature-engineering/</link><description>Recent content in Feature-Engineering on Varchaleswari Ganugapati</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 13 May 2026 10:00:00 -0600</lastBuildDate><atom:link href="https://varchaleswariganugapati.com/tags/feature-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Powering Models: Feature Engineering, Part 2</title><link>https://varchaleswariganugapati.com/post/powering-models-feature-engineering-part-2/</link><pubDate>Wed, 13 May 2026 10:00:00 -0600</pubDate><guid>https://varchaleswariganugapati.com/post/powering-models-feature-engineering-part-2/</guid><description>&lt;p&gt;Part 1 covered the offline side: getting features built, validated, and automated. This post picks up at the point where a model is deployed and a service needs to call it.&lt;/p&gt;
&lt;p&gt;The question is deceptively simple: how does the model get the features it needs when a request comes in?&lt;/p&gt;
&lt;p&gt;There are two answers, and most real systems use both depending on the feature type.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-two-patterns"&gt;The two patterns&lt;/h2&gt;
&lt;pre class="mermaid"&gt;
 flowchart LR
 classDef caller fill:#eff6ff,stroke:#3b82f6,stroke-width:1.5px,color:#1e3a5f
 classDef svc fill:#f5f3ff,stroke:#8b5cf6,stroke-width:1.5px,color:#3b0764
 classDef model fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
 classDef store fill:#fefce8,stroke:#eab308,stroke-width:2px,color:#713f12

 subgraph patternA[&amp;#34; Pattern A · Features in the request &amp;#34;]
 C1[Client / Caller]:::caller --&amp;gt;|&amp;#34;payload includes features&amp;#34;| SVC1[Prediction Service]:::svc
 SVC1 --&amp;gt; M1[Model]:::model
 M1 --&amp;gt;|prediction| C1
 end

 subgraph patternB[&amp;#34; Pattern B · Features from online store &amp;#34;]
 C2[Client / Caller]:::caller --&amp;gt;|&amp;#34;entity ID only&amp;#34;| SVC2[Prediction Service]:::svc
 SVC2 --&amp;gt;|&amp;#34;fetch features&amp;#34;| FS[(&amp;#34;Online Feature Store&amp;#34;)]:::store
 FS --&amp;gt;|&amp;#34;feature vector&amp;#34;| SVC2
 SVC2 --&amp;gt; M2[Model]:::model
 M2 --&amp;gt;|prediction| C2
 end
&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Pattern A&lt;/strong&gt; puts the burden on the caller. The upstream service computes or collects the features and sends them as part of the request payload.&lt;/p&gt;</description></item><item><title>Powering Models: Feature Engineering, Part 1</title><link>https://varchaleswariganugapati.com/post/offline-model-building-vs-serving-in-production/</link><pubDate>Wed, 13 May 2026 09:00:00 -0600</pubDate><guid>https://varchaleswariganugapati.com/post/offline-model-building-vs-serving-in-production/</guid><description>&lt;p&gt;The moment a model ships, you start paying for every shortcut taken before it.&lt;/p&gt;
&lt;p&gt;Most ML failures in production aren&amp;rsquo;t model failures. They&amp;rsquo;re pipeline failures. The wrong features. Features computed differently at training time versus serving time. No one owning the handoff between the data science team and the engineering team. Pipelines that worked once but weren&amp;rsquo;t designed to run again.&lt;/p&gt;
&lt;p&gt;This post is about the offline half of the ML lifecycle: how features get discovered, engineered, and automated into repeatable pipelines, and why the decisions made here directly determine what&amp;rsquo;s possible in production.&lt;/p&gt;</description></item></channel></rss>