What Would RAG Look Like If Miranda Priestly Were the User?

Somewhere at the intersection of cloud computing, open source software, and fashion, there’s an Akamai T-shirt.

Akamai teamed up with UNIQLO for its PEACE FOR ALL charity T-shirt project, bringing the company’s digital roots into the physical world. The design features a heart on the front and real computer code on the back, a reference to Linux, and the open source foundations of the internet. 

Seeing computer code translated into a T-shirt made me wonder whether the process could work in reverse: If technology can become fashion, can fashion become something that AI can understand and search? More specifically, what kind of retrieval-augmented generation (RAG) system would an international team of fashion designers actually want?

Then, Miranda Priestly entered the architecture.

I was watching The Devil Wears Prada 2 during a long flight when the idea became more concrete. Somewhere between the fashion, the impossible deadlines, and Miranda Priestly’s famously exacting expectations (she is the formidable, cold, and razor-sharp Editor-in-Chief of Runway, a fictional high-fashion magazine in the film), I started thinking about what an enterprise AI assistant for a fashion organization would actually need to do.

Imagine a designer asking, “Show me previous women’s jackets with a silhouette like this, but with a shorter collar.” Or a Japanese designer searching for a warm winter coat in Japanese, followed by an Italian designer refining the same search in Italian.

A conventional text-based RAG system can search descriptions, documents, and metadata. But what the designer is looking for may not exist in the words at all. It may be in the pixels: the silhouette, pattern, color, cut, or visual relationship between one design and another.

That led to an engineering question: Could I build a RAG system that would let fashion teams search visual archives in the way designers actually think, in a way that might even earn a small nod of approval from Miranda Priestly?

I called it Miranda.

The result illustrates the problem nicely. Text retrieval can be excellent when the information that we need is represented in text, and optical character recognition (OCR) can help when words are embedded inside images or documents.

Neither, however, necessarily represents the design itself.

A fashion archive is fundamentally multimodal, so instead of asking an LLM to somehow infer the visual content of hundreds of thousands of images, I tried something simpler: I turned the images into vectors.

There’s no vector database in this experiment, and there isn't even Facebook AI Similarity Search (FAISS).

The retrieval operation is essentially:

In this operation, q is the normalized query embedding, E is the matrix containing the normalized image embeddings, and S is the score of similarity. Once those scores are calculated, the retrieval step selects the highest-scoring images (K).

In other words, one matrix multiplication compares the query against all the image vectors, and the highest scores become the results. The source code and reproducibility instructions for the Miranda experiment are available.

I started small, with 500 images. Then I moved to 5,000, 50,000, and then 200,000.

Eventually, the experiment reached 289,222 images, represented by 512-dimensional vectors, with a complete FP32 embedding matrix of roughly 565 MiB. On my Mac, using Apple's MPS back end, searching the entire matrix with PyTorch GEMM remained remarkably fast. In one run, generating the CLIP text embedding took 162.3 milliseconds, while comparing it against all 289,222 image vectors took just 10.8 milliseconds. 

The exact numbers vary from run to run, but the pattern was consistent enough to get my attention.

What this showed me was that retrieval itself wasn’t necessarily the expensive part. Often, more time was spent on everything surrounding it.

That leads to an engineering principle that I keep returning to: Measure the system that you actually have before adding infrastructure for the system you imagine you will eventually have.

A vector database may absolutely become the right architecture as the scale or requirements change, especially when you need distributed storage, filtering, frequent updates, billions of vectors, durability, multi-tenancy, or other capabilities. But I don't think “RAG” should automatically imply “vector database.”

Sometimes a matrix is enough.

My first multilingual implementation sent essentially every query through a local LLM. It worked, but it also meant using the LLM for queries that didn’t really need it.

For example, if somebody types “black winter coat,” the intent is already clear.

Why spend seconds asking an LLM to transform a perfectly usable English fashion query into another English fashion query?

To that end, I added routing. Straightforward English fashion searches bypass the LLM and go directly to CLIP, while Japanese, Italian, and other multilingual requests can use the local LLM to normalize the user's intent into concise English before CLIP embedding.

That gives each component a clear job: The LLM interprets language, CLIP represents the search intent in the same embedding space as the images, and GEMM retrieves the nearest vectors.

That separation turned out to be one of the most important architectural lessons I learned from the experiment. An LLM makes sense where language reasoning adds value. Elsewhere, however, a simpler component may already do the job well.

During development, Miranda occasionally misunderstood a follow-up request. Rather than hide everything behind a polished chatbot response, I exposed the intermediate representation so I could see what was happening between the user’s request and the search (Figure 3).

That visibility proved enormously useful. When the retrieval result looked wrong, I could immediately see whether CLIP struggled with the search or whether the language layer had handed it the wrong query in the first place.

For AI systems, observability shouldn't stop at CPU, memory, and HTTP latency. It can also include exposing, or at least logging, the transformations that happen as information moves among models, because those intermediate representations are often where the bug actually lives.

Because my professional background is in security, I couldn't resist attacking my own fashion chatbot.

I asked Miranda to write a C++ Hello World program.

Clearly, that isn’t what a fashion search assistant is supposed to do, even if an LLM sits behind the interface. That exposed the need for a domain gate: a control that would keep Miranda focused on fashion-related requests and reject prompts outside that intended use.

But once I added that boundary, I discovered the opposite problem. Consider these two prompts:

The word code appears in both, but their intent is completely different. The first should be rejected, but the second is a completely legitimate fashion request.

A simple blocklist of suspicious words wasn’t going to work. The system had to understand context, which points to a broader security principle: Security controls need to understand the system’s intended capability rather than reacting only to individual tokens appearing in a prompt.

Thinking through those boundaries while Miranda was still a prototype was much easier than trying to bolt them on later.

The entire experiment began on an Apple Silicon Mac, with OpenCLIP and PyTorch retrieval running through MPS while the language model and fashion archive remained local. That wasn't just convenient.

For enterprise design archives, the images themselves may represent valuable intellectual property, and a design team may reasonably prefer an architecture in which proprietary designs don't have to leave an environment under its control simply to make them searchable.

And, because the PyTorch code already selects between MPS and CUDA, the same basic architecture can move from a Mac prototype to an NVIDIA GPU without redesigning the application.

Doing so creates a practical path from prototype to production: Start locally, measure what’s actually happening, and then scale the component that needs it.

That same approach can extend to where those workloads run. As a visual search application moves into production and needs to support more users, larger archives, or globally distributed teams, the CUDA-based components can move to distributed GPU infrastructure without changing the basic retrieval design.

The surrounding results were in exactly the semantic neighborhood I hoped to see: T-shirts containing binary digits, technical-looking text, and other computer-related graphics.

In that run, the GEMM retrieval took about 10.8 milliseconds. 

The result closed the loop in a way that I hadn’t planned. Akamai and UNIQLO put code onto a T-shirt, which helped me think about what AI-native search might mean for fashion. I turned that fashion into vectors, searched those vectors for a nerdy T-shirt with computer code, and the system found the Akamai shirt again without being told to look for Akamai.

How wonderfully circular.