Blog
Essays·2 min read

Most of your data problems are not AI problems

Before we put a vector database in front of anything, we ask one question with a default answer of no. It has saved more projects than any model choice we've made.

By VRTKL MEDIA

The studio desk with nobody at it: a graded shot held on the monitor, an edit timeline on the laptop, studio monitors, a small amp and a MIDI keyboard.

A version of this conversation happens on almost every engagement. Someone describes a real problem — nobody can find last quarter's numbers, the sales team keeps asking the same five questions, the reports take a day to assemble — and the proposed shape of the answer is an AI that has read everything.

Sometimes that's right. Usually the data is already structured, already in a database, and the question has an exact answer that a query returns in milliseconds. Retrieval over embeddings gives you an approximate answer to a question that had an exact one, and charges you a model call for the privilege.

The check

So we make ourselves stop at two points — when the work is scoped, and again before anyone writes retrieval code — and ask:

Is this data structured? If yes, the answer is SQL, not vectors.

The default is no. Not "probably not" — no, unless someone can say specifically why the structured path fails. That reversal matters, because the enthusiastic answer is always yes and enthusiasm is not a design input.

When it genuinely is a retrieval problem

  • The source is prose nobody controls — contracts, terms of reference, transcripts, email threads.

  • The question is about meaning rather than value: "what did we agree about penalties", not "what was the penalty amount".

  • The corpus is large enough that a person reading it is the actual bottleneck.

Those are real, and we build for them. Tender documents are a good example: a hundred pages of prose where the thing you need is a qualification threshold buried in an annex.

Why this is worth saying out loud

Because the expensive failure isn't picking the wrong model. It's building an impressive system that answers approximately, on top of data that could have answered exactly, and then spending months tuning the approximation. The cheapest AI project is the one you correctly decide not to build.

That's not a position against AI. We build automation for a living. It's a position that the interesting judgment happens before the model does, and a partner who never talks you out of anything isn't giving you judgment.

  • ai
  • architecture
  • consulting

Let's build something worth writing about.

Automation, workflow systems, film — start with a conversation.

Start a project