# Stitch Fix Stitch Fix is a full-stack startup creating unique solutions in data-driven merchandising, massively scaled personal styling, and complex logistics. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Stitch Fix's Move to Kubernetes for More Agile Service Deployment DevFeed: [Stitch Fix's Move to Kubernetes for More Agile Service Deployment]() Original publisher: [Read original article]() Published: 2023-09-19T15:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Deployment](), [Kubernetes](), [Amazon Elastic Kubernetes Service](), [Microservice](), [autoscaling](), [Apache Spark]() Tags: [autoscaling](), [deployment](), [emr](), [golang](), [kubernetes](), [microservices](), [nodejs](), [python](), [scala](), [spark]() ### AI overview This article describes Stitch Fix's effort to improve service deployment agility. It explains the platform's self-service goals, its transition from EMR-based Spark infrastructure to EKS, and the deployment challenges that motivated consideration of Kubernetes for core platform services, including standardization across languages, autoscaling, rollback, and traffic segmentation. ### Source excerpt Introduction At Stitch Fix, our data platform is designed to be self-service, with our users taking ownership of their own ETL, models, and microservices. To support this approach, the platform team prioritizes user autonomy and end-to-end tooling in their tooling designs, minimizing the involvement of platform engineers in day-to-day engineering and data science workflows. We regularly evaluate our infrastructure against new frameworks to assess the costs and benefits of potential updates. Last year, we transitioned our EMR-based Spark infrastructure to EKS to take advantage of its benefits. The next logical step was to re-examine how our core platform services were deployed and updated, especially those still deployed directly to instances. We also recognized that Kubernetes, a popular open-source system for handling the deployment of containerized applications, could provide benefits for microservice orchestration beyond just batch compute infrastructure. Our existing instance-based service deployment framework was beginning to show its age in areas that were critical for Stitch Fix, such as the development lifecycle's velocity. As we saw an opportunity to leverage Kubernetes to address these issues, we identified pain points in our service deployment ecosystem. Pain Points Building and deploying services can be a time-consuming process, involving multiple steps and dependencies. We needed a solution that would streamline this process and enable us to deploy services more efficiently. Polyglot environments, where multiple programming languages are used within the same system, can present a challenge for deployment standardization. At Stitch Fix, we use a variety of languages, including Python, Golang, Nodejs, and JVM (Java and Scala), making it difficult to establish consistent deployment practices across the board. We needed a way to deploy polyglot environments in a standardized and efficient manner. Autoscaling and rollback capabilities are essential for manag ## Ariadne: building a custom observability UI for personalized search DevFeed: [Ariadne: building a custom observability UI for personalized search]() Original publisher: [Read original article]() Published: 2023-06-13T01:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [observability](), [ui](), [React](), [d3.js](), [Microservice](), [Logging and metrics](), [debugging]() Tags: [d3-js](), [debugging](), [development](), [logging-and-metrics](), [microservices](), [observability](), [react](), [ui]() ### AI overview Stitch Fix describes Ariadne, a custom interactive observability UI for introspecting its personalized search pipeline. Built with React, D3.js, visx, and internal libraries, the tool uses production and experimental search APIs to help teams trace search behavior, diagnose bugs, and support experimentation. ### Source excerpt In June 2022, Stitch Fix launched the Freestyle search feature, transforming how our clients discover styles that are tailored to their taste. Under the hood, personalized search is fulfilled by a pipeline of modular microservices. We designed the search system to be composable, making it easy to swap in new components and speeding up experimentation and development. Composability also made the system more observable, making it simpler to make each event traceable and reproducible with built-in logging and metrics. However, even with extensive logging, debugging a complex system such as personalized search can be quite challenging. As a hypothetical example, if a client searches for running shoes and instead sees paisley sweaters, we need to quickly diagnose where in the search pipeline the problem occurred, so that the experts in that system can work on a resolution. Where did the sweaters come from, and where are the shoes we expected to see instead? Did the query get parsed into incorrect attributes? Did the attributes get poorly matched with items in our inventory? Did the result rankings disproportionately focus on the client's past preference for sweaters and disinterest in sportswear? Understanding which service is responsible for the problem is a crucial first step in addressing it. Ideally, we want to anticipate and prevent such problems through interrogating hypothetical search scenarios before clients encounter them. Early on, we knew that slogging through system logs to understand bugs and dependencies of search would not sustain our need for iterative experimentation and collaborative development. To reduce toil and enhance the impact of the Search team, we invested in building a dedicated tool. Ariadne, named after the labyrinth expert from Greek mythology, is a custom interactive UI designed for search introspection. Ariadne is built with React and custom visualization components based on D3.js, visx, and internal libraries, and is powered by producti ## Implementing Multi-GPU Distributed Training for Stitch Fix's Personalized Recommendations DevFeed: [Implementing Multi-GPU Distributed Training for Stitch Fix's Personalized Recommendations]() Original publisher: [Read original article]() Published: 2023-06-08T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [distributed-training](), [recommendations](), [GPU](), [sharding](), [Training AI Models](), [Multi-GPU](), [PyTorch]() Tags: [distributed-training](), [gpu](), [model-training](), [multi-gpu](), [parallel](), [performance](), [pytorch](), [recommendations](), [sharding]() ### AI overview This Stitch Fix engineering article explains how the company implemented multi-GPU distributed training for its Client Time Series Model (CTSM), a PyTorch-based model used in personalized recommendations. It describes sharding training data across GPUs and training mini-batches in parallel to reduce training time, along with the surrounding retraining and deployment workflow. ### Source excerpt Stitch Fix uses a cutting-edge multi-tiered recommender system stack to personalize styling recommendations at scale. This stack comprises several critical components, including feature generation, scoring, ranking, and inventory optimization techniques. Our scoring module is based on the Client Time Series Model (CTSM) which is an award winning novel sequence based model that uses temporally masked encoders. CTSM is built using PyTorch, and was initially trained on a single Graphics Processing Unit (GPU) instance. Since we first put this model into production last year, we have launched several updates to the model that improved its performance. Many of these improvements involved adding new features or increasing the time window of our training data. As a result, the model training time increased significantly, making it harder for us to iterate quickly and get feedback on new ideas we want to try for improving the model. We needed a way to reduce the model training time. This blog delves into the steps we followed to overcome this challenge and our journey to implement multi-GPU distributed model training for CTSM. By sharding the training data across multiple GPUs and training multiple mini-batches in parallel, we aimed to achieve significant reductions in training time. We present empirical results showcasing the observed reduction in training time when we scaled up resources from 1 to N GPUs, and share some future directions we are considering in our continued effort to speed up model training. Model Training Workflow The scores generated by CTSM are leveraged by multiple downstream services to get insight into what items a client is likely to purchase. The model is retrained at a regular cadence to ensure that it is using the most updated information about each client when making predictions and does not degrade in its performance. We leverage configuration driven machine learning pipelines to set up a Directed Acyclic Graph (DAG) that automatically retrains ## Expert-in-the-loop generative AI for text generation at Stitch Fix DevFeed: [Expert-in-the-loop generative AI for text generation at Stitch Fix]() Original publisher: [Read original article]() Published: 2023-03-06T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Generative AI](), [Large Language Model](), [text-generation](), [Deep learning](), [data](), [Embeddings]() Tags: [data](), [deep-learning](), [embeddings](), [few-shot](), [generative-ai](), [large-language-models-llms](), [text-generation]() ### AI overview Stitch Fix describes using generative AI and large language models for text-generation tasks, including advertisement headlines and product descriptions, with human experts involved in the process. ### Source excerpt Generative AI has been gaining attention and popularity in recent years. Made possible with advances in deep learning algorithms and trained with previously unimaginable amounts of data, generative AI has already contributed many real-world use cases, from creating realistic images with systems like DALL-E 2 and Midjourney, to generating human-like responses with ChatGPT. At Stitch Fix, we are constantly exploring innovative ways to utilize the latest advancements in AI and ML to enhance the experiences of our clients. In this blog post, we will delve into our approach to generative AI, with a special focus on our text generation use cases. By combining algo-generated text with a human expert-in-the-loop approach, we aim to streamline tasks such as crafting engaging advertisement headlines and producing high-fidelity product descriptions. Algo-generated Ad Headlines Generative AI in the text space is powered by large language models (LLMs) that are pre-trained on vast amounts of data (for example, GPT-3 is pre-trained on nearly the entire internet) and can understand and generate natural language. However, once pre-trained, it can generalize from very limited amounts of data and is capable of performing a wide variety of natural language tasks such as Q&A, translation, summarization, and text generation. This few-shot learning capability, which relies only on a few examples to make predictions, makes it especially well suited for tasks that require creativity and originality, such as crafting compelling ad headlines. Ad headlines are often the first interaction with potential clients, so it's crucial to make them engaging. Traditional marketing requires a copywriter to write new headlines for every new ad asset, which can be time consuming and costly, and may not always result in unique copy. Using generative AI, such as GPT-3, we can quickly generate a large number of headlines tailored to our brand tone and messaging. We achieve this by using a combination of late ## Polymorphic, Recursive Interfaces Using Go Generics DevFeed: [Polymorphic, Recursive Interfaces Using Go Generics]() Original publisher: [Read original article]() Published: 2023-02-01T09:00:00Z Content type: tutorial Language: en Sources: [Stitch Fix]() Topics: [Go Language](), [generics](), [interfaces]() Tags: [code](), [generics](), [go](), [interfaces]() ### AI overview The article explains how Go generics enable polymorphic interfaces whose methods return the concrete receiver type, using logger implementations as an example. It also discusses the limitations of Go's type inference, which can require explicit type parameters when using these interfaces. ### Source excerpt I did a bit of experimenting over the weekend in an attempt to figure out how to write an interface that abstracted over methods whose return type was identical to the receiver's type. This is frequently a thing that one wants to do when abstracting over self-cloning objects, or things that implement the Builder pattern. For example, suppose we have a struct through which we log stuff: type StdoutLogger struct { out ioutil.Writer outMu sync.Mutex fields map[string]interface{} } func (n *StdoutLogger) WithFields(fields map[string]interface{}) (out *StdoutLogger) { for k, v := range fields { out.fields[k] = v } return } func (n *StdoutLogger) Infof(format string, args ...interface{}) { n.outMu.Lock() defer n.outMu.Unlock() s := fmt.Sprintf(format, args...) if len(n.fields) > 0 { s += " " } for k, v := range n.fields { s += fmt.Sprintf("%s=%+v", k, v) } n.out.Write([]byte(s)) } ...and we've got some other struct that we use during test which ignores all requests to log stuff: type NoopLogger struct {} func (n *NoopLogger) WithFields(fields map[string]interface{}) *NoopLogger { return n } func (n NoopLogger) Infof(format string, args ...interface{}) { return } Before Go Generics Before the Go "generics" feature was released, defining an interface that abstracted over both structs was not possible (link). For example, if we had a pre-generics interface that looked like: type Logger interface { WithFields(fields map[string]interface{}) Logger Infof(format string, args ...interface{}) } ...there would be no way to satisfy it with types that had these signatures: func (n *NoopLogger) WithFields(fields map[string]interface{}) *NoopLogger func (n *StdoutLogger) WithFields(fields map[string]interface{}) *StdoutLogger ...because of the different return types of each struct's WithFields method. Polymorphic Interfaces Now that generics have landed, we can define an interface that abstracts over both of these structs: type Logger[T any] interface { WithFields(fields map[string]interface ## 2022 Intern Projects DevFeed: [2022 Intern Projects]() Original publisher: [Read original article]() Published: 2023-01-03T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Algorithms, Complexity](), [Data Science](), [personalization](), [Query (disambiguation)](), [Availability](), [client]() Tags: [algorithms](), [availability](), [data-science](), [personalization](), [search]() ### AI overview This article presents projects by four Stitch Fix interns. One project examined how inventory allocation affects personalized search in Stitch Fix Freestyle, using personalization and relevance metrics and comparing them with client satisfaction while accounting for inventory availability. ### Source excerpt Earlier this year, we had four fantastic interns join our Algorithms team for 3 months to learn how we harness data science in our work at Stitch Fix. These four interns hail from across the country and spent their time exploring a specific project and advancing their skills in their unique interest areas. In their own words below, they've showcased each of their own projects and the meaningful insights they were able to uncover in their short time with us. Optimizing inventory allocation for client-facing search Maria Olaru, PhD candidate in Computational Neuroscience at University of California - San Francisco In an effort to expand beyond its core business of Fixes, a service where stylists select five personalized items and send them straight to clients' doors, Stitch Fix launched Freestyle. Freestyle is a personalized and instantly shoppable feed of items that clients can directly buy outside of their Fix. Within Freestyle, Stitch Fix recently launched a Search feature, allowing clients to directly query personalized items. I spent my time at Stitch Fix investigating how to optimize Stitch Fix's existing inventory allocation to better serve customers who use Search within Freestyle to search for products. For my project, I chose inventory-related metrics to explore, collected the corresponding data, and compared these metrics to client satisfaction. I chose inventory-related metrics that I could compare to client satisfaction: personalization and relevance. Personalization captures how well our items reflect clients' individual style, while relevance captures accurately our items reflect what a client asked for. With Fix orders, we view personalization as a top metric that predicts client purchases. However, Freestyle differs from Fix in a crucial manner: clients using Fix are not asking for a specific item, whereas clients using Search within Freestyle know what they want, and are explicitly looking for it. Next, I collected data for these metrics. To explore ## Leveraging the Plain Old Python Function DevFeed: [Leveraging the Plain Old Python Function]() Original publisher: [Read original article]() Published: 2022-12-14T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Python](), [MLOps](), [Data Science](), [Framework](), [Deployment]() Tags: [apis](), [blog-post](), [dsl](), [functional](), [microservices](), [mlops](), [model-deployment](), [python]() ### AI overview Stitch Fix describes a function-first approach to data science APIs and MLOps. Instead of building custom model-deployment mechanisms, microservices, and tightly coupled data transformations, data scientists can use plain Python functions backed by platform infrastructure. ### Source excerpt The role of the full-stack-data-scientist is not what it once was. With the advent of more powerful tooling, new industry standards in MLOps, and greater investment in platforms, the day-to-day of a data scientist has changed significantly at Stitch Fix. The difference, however, is subtle. The structure of their job remains the same - engineers still do not write ETLs and data scientists function as generalists, but they now have to think on a higher level. Their job is constantly getting more and more complex--the business needs are in flux and the infrastructure they use is more powerful than it ever was. The old strategy of cobbling together complex systems will only end in stressed-out data scientists with too much infrastructure on their plate. To avoid this cycle of complexity, Stitch Fix invests in a platform team to innovate new ways of supporting a data scientist's engineering needs. Rather than constructing custom model-deployment mechanisms, building microservices from the ground up, and managing highly interdependent chains of data transformations, data scientists at Stitch Fix can leverage powerful infrastructure by constructing plain old Python functions to represent their needs. In this blog post we're going to take a different approach than usual. Rather than digging into a specific piece of technology, we'll present our philosophy of functions for data science APIs and back it up with some motivating examples. We'll explain the power of functions as a DSL, share some successes we've had using functional interfaces to build our MLOps stack, and connect our approach with external, open-source frameworks that the industry is beginning to adopt. Our goal is to convince you that a function-first approach will enable data practitioners to do more while doing less. The functional approach allows them to plug into the business in a scalable manner while avoiding the complexity of managing infrastructure and architectural decisions. On Functions and Functiona ## Client Time Series Model: a Multi-Target Recommender System based on Temporally-Masked Encoders DevFeed: [Client Time Series Model: a Multi-Target Recommender System based on Temporally-Masked Encoders]() Original publisher: [Read original article]() Published: 2022-10-14T06:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [client](), [Time Series](), [recommendations](), [Embeddings](), [model architecture](), [maintenance](), [systems](), [data]() Tags: [data](), [embeddings](), [maintenance](), [model-architecture](), [recommendations](), [systems](), [time-series]() ### AI overview Stitch Fix describes its Client Time Series Model, a sequence-based recommender that estimates the probability of client-item purchases. The model uses a unified client embedding and incorporates the time dimension of client interactions to reduce duplicated models, improve maintainability, and share learning across business lines, regions, and channels. ### Source excerpt Introduction The foundation of our recommendation stack is a scoring model we call p(sale), which estimates the probability that any given client will purchase any given item. This model has gone through many iterations over the years, from a mixed effects model, to a matrix factorization model, and now to a novel sequence-based model. Internally we call this the Client Time Series Model (aka CTSM) because of its focus on the time-domain of client interactions. This post details our new model, which is a significant improvement for both the quality of our recommendations and the maintainability of our systems. Motivation Before setting out to develop our new model, it was clear that the evolution of our business necessitated a change to our modeling approach. First, the growing variety of recommendations we serve led to an explosion in the number of models we needed to maintain. Each time the business expanded, such as adding Mens, or serving the UK, or adding direct shopping with Freestyle, we responded by forking a new model to serve the new channel. This was necessary because a single domain-agnostic model could not serve the new channels as well as tailored models, but over time it has increased our maintenance burden and cost of iteration. In addition to the system complexity, we also knew we had an opportunity to make better use of important signals. With data and models separated by business line, region, and channel, we had a limited ability to leverage learning across these boundaries. With a unified model, we can more seamlessly use data from US clients to improve recommendations for UK clients, or data from Fixes to improve recommendations in Freestyle. Finally, our previous approaches modeled clients via tabular data. Although they are trained on purchase events that take place in the context of a particular point in time, they did not explicitly consider the time dimension in their understanding of the client's interactions. We believed that there was s ## Algo Hour - Large Scale Data & ML Monitoring with whylogs | Alessya Visnjic DevFeed: [Algo Hour - Large Scale Data & ML Monitoring with whylogs | Alessya Visnjic]() Original publisher: [Read original article]() Published: 2022-09-29T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Data Quality](), [data observability](), [Monitoring](), [Machine learning](), [ai observability]() Tags: [data](), [data-ml](), [data-pipelines](), [data-quality](), [monitoring](), [observability](), [open-source]() ### AI overview This talk explains how the open-source whylogs library supports end-to-end data quality and monitoring across machine learning pipelines. It covers whylogs' lightweight statistical data collection, language- and platform-agnostic approach, architecture, and application to existing data and ML pipelines. ### Source excerpt Title: Large Scale Data & ML Monitoring with whylogs Talk Abstract: In the era of microservices, decentralized ML architectures and complex data pipelines, data quality has become a bigger challenge than ever. When data is involved in complex business processes and decisions, bad data can, and will, affect the bottom line. As a result, ensuring data quality across the entire ML pipeline is both costly, and cumbersome while data monitoring is often fragmented and performed ad hoc. An open source library called whylogs is built to address these challenges. It is a lightweight data profiling library that enables end-to-end data monitoring across the entire software stack. The library implements a language and platform agnostic approach to data quality and data monitoring. It's been deployed at massive-scale data environments, on structured and unstructured data modalities, and across a range of points in the ML lifecycle. In this talk, we will provide an overview of the whylogs architecture, including its lightweight statistical data collection approach and we will show how users can apply this library to existing data and ML pipelines. Date and Time: The talk will be held on Tuesday, October 11th at 1:00PM PDT. Recording Info: This talk was recorded live and is viewable below: Speaker Info: Alessya Visnjic is the CEO of WhyLabs, the AI Observability company building tools that power robust and responsible AI deployment. Prior to WhyLabs, Alessya was a CTO-in-residence at the Allen Institute for AI, where she evaluated commercial potential for the latest AI research. Earlier, Alessya spent 9 years at Amazon leading ML initiatives, including forecasting and data science platforms. Alessya is also the founder of Rsqrd AI, a global community of 1,000+ AI practitioners who are committed to making enterprise AI technology responsible. ## Experts in-the-Loop at Stitch Fix DevFeed: [Experts in-the-Loop at Stitch Fix]() Original publisher: [Read original article]() Published: 2022-09-02T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [personalization](), [recommendations](), [datasets](), [Training AI Models]() Tags: [customer](), [datasets](), [e-commerce](), [personalization](), [recommendations](), [training](), [training-data]() ### AI overview Stitch Fix describes how human stylists help create high-quality training data for personalized outfit recommendations in its Freestyle direct-shopping experience. The article explains why stylist judgments are needed to assess recommendation quality and client experience at scale. ### Source excerpt Imagine your job is to personalize search results on an e-commerce site for returning customers, classify the presence or absence of pedestrians in street photos, or develop an app that translates languages. In all of these cases, a basic ingredient is a dataset of annotations provided by a human. For any company seeking to personalize experience for its customers, combining human computation with algorithmic computation is essential. This is also true for Stitch Fix. At Stitch Fix, we recently launched Stitch Fix Freestyle, our direct-shopping experience, where our algorithmic recommendations are now directly shared with clients in their own personal shopping feed - a different approach from our original Fix experience, where a team of expert stylists determined what should go in the client's Fix. Central to the Freestyle experience for clients is showing individual items as part of complete outfits, where both items and outfits are personalized based on our clients unique size, fit, style, and price preferences. But, what makes a good outfit? And, how do we balance personalization to a customer with a given level of outfit quality or a particular stylistic slant? In order to bootstrap a new product like this, to offer personalized outfit recommendations at scale to our around 4m clients, we need some high-quality training data. In particular, we need data specific to what it means to have a good client experience - or what makes a good outfit for a given client at Stitch Fix. Datasets like this aren't exactly floating around: assembling them requires an intentional, large-scale effort. The best way to get high-quality data sets is to work with our in-house experts: our stylists. In this post, you'll learn more about the purpose and impact of stylist-in-the-loop projects, and the powerful impact that our stylists have in building the future of personalized shopping. Bringing in our "experts in-the-loop" Working with our expert stylists helps us improve our clients'