Buy or build: grounded answers over your own content

Most teams that decide to build this are not wrong to think they can. The first version genuinely does take a week. What follows is an account of what arrives after that week — written by people who built it, and who would rather you made this decision with the real inventory in front of you than discover it in month four.

The week-one version

Chunk your documents, embed the chunks, put the vectors in a store, embed the query, retrieve the nearest neighbours, stuff them into a prompt. This works. It demos well. On a few thousand documents with one person using it, it is genuinely hard to distinguish from a mature system.

That is the trap, and it is not a trap about quality. It is a trap about which problems have shown up yet. Everything below is a problem that only appears with concurrency, scale, a second content source, or time.

What arrives with the second source system

The single-source version of this problem is a search box. The multi-source version is a different product, and the difference is entity resolution.

Your help centre calls it "SSO". Your tickets call it "single sign on", "single-sign-on", and occasionally "SAML". Your onboarding course calls it "identity federation". A vector search will partly paper over this, because embeddings are tolerant of surface variation. A graph will not: you get four nodes, none of which knows about the others, and the traversal that was supposed to connect your content instead fragments it.

So you build resolution, and the first version arrives in an afternoon. It handles the easy cases, and every case it misses wants a more expensive kind of comparison than the last — up to two teams whose words for one thing share no characters at all. Each one is cheap to describe and considerably less cheap to get right.

Then you make extraction concurrent, because sequential extraction over a real corpus takes days, and the whole thing breaks in a way that is genuinely hard to see.

There is a correct answer and it is not the one you reach for first, which is the point: this is the first place where the week-one version stops being a week. Nothing in your test suite will tell you that you have got it wrong, because the failure needs real concurrency over a real corpus to appear, and by then the duplicates are written.

What arrives with provenance

The naive graph stores facts: subject, predicate, object. It works until someone asks the obvious question — which document said that? — and you discover you did not keep it.

So you add a document reference to the edge. Then two documents assert the same fact, and you have to decide: two edges, or one edge with two references? Two edges means your traversals double-count and your corroboration numbers are meaningless. One edge with a set of references means you need a join table, and now you have to decide what happens when one of those documents is deleted.

Whatever you land on has to pass one test: delete one document out of four that assert the same fact. Most designs either destroy a fact that three documents still support, or leave a fact standing that nothing supports any more. Getting that right takes a while, and it is bookkeeping you carry for as long as the graph exists.

What arrives with the ontology

You have to tell the extractor what to look for. So you write a list of entity types, and because you write it before you have seen what your corpus contains, it is wrong. That is not a criticism — it is unavoidable. Nobody knows their own vocabulary until they have extracted it.

The question is what happens when you want to change it. In most implementations the answer is: nothing good. Changing an entity type means the entities already typed with the old one are wrong, and your options are to delete them, to retype them with another model pass, or to leave them and accept an inconsistent graph.

All three are bad enough that the actual outcome is predictable: nobody changes the vocabulary. It freezes at whatever the first guess was, the corpus grows past it, answers get quietly worse, and the reason is invisible because there is no metric for "our taxonomy stopped matching our content".

What you actually need is for a vocabulary change to be reversible: applying a new version loses nothing, going back to the previous one restores the earlier view whole, and the model never re-runs either way. That property is not hard to want and it is easy to build the wrong way round; the difference it makes is between a vocabulary your team maintains and one they are afraid of.

What arrives with orchestration

This is the part that is easiest to underestimate, because none of it is on the feature list and all of it is discovered late.

A naive pipeline processes a document inside the request that submitted it. That works until the work takes longer than something in the path is willing to wait — a load balancer, a proxy, a client timeout — at which point the connection is severed and the half-finished work goes with it. The caller already has a success response. Nothing errors, nothing retries, and the document is simply not there.

Around that sit three more problems with the same shape, and each is its own project rather than a line on a feature list: surviving a provider rate limit without losing what was in flight, keeping one tenant's backfill from starving everyone else, and recovering from a bad deploy without asking your callers to re-send. None of them is exotic. All of them arrive at once, late, and in production.

None of that is exotic. All of it is work, and all of it is work you would be doing rather than working on your product.

What it actually costs

The model spend is the part everyone worries about, and it is the most predictable part: graph extraction is paid once per document, at ingest, and every search then makes a model call of its own to write the answer.

• Model spend: proportional to how much you ingest and how often you search, and a line item rather than a decision.
• Datastores: a vector index, and usually a graph database. Both need sizing, backups, monitoring and a rebuild path. This is real money and real operational surface.
• The engineer: one person who understands the whole pipeline and is on the hook when a document does not show up. This is the actual cost, and it does not end.

The four questions that decide it

Everything above is context. These are the questions that actually determine the answer, and two of them point at building.

1. Is retrieval quality what your customers buy from you? If your product IS search, or if a percentage point of relevance is your differentiator, build it. You will out-tune any general-purpose service on your specific corpus, because you can afford to care about it more than we can.
2. Do you have a hard deployment or model constraint? Your own cloud, a specific region, a specific model, customer-managed keys. If any of these is non-negotiable, build — we offer one managed deployment in one region on models we choose, and no amount of goodwill changes that this quarter.
3. Can you staff the pipeline indefinitely? Not build it — own it. Through the person who wrote it leaving, through the model deprecation, through the day a store loses a collection. If the honest answer is that it becomes nobody's job after launch, buying is the lower-risk path.
4. Does your content span more than one system? If it does, the expensive parts above are all in your path: resolution across vocabularies, provenance across sources, a vocabulary that needs governing. If it does not — one source, one taxonomy — the week-one version may genuinely be enough, and you should not buy a graph to solve a problem you do not have.

What we would tell you on a call

That the trial exists precisely so this decision does not need a meeting. Fourteen days on the graph tier, 2,500 documents, no card — so you are testing the thing you would actually buy rather than a reduced version of it. Point it at a real slice of your content and ask it real questions. An afternoon of that is worth more than any comparison document, including this one.

And that if the answers are not useful, the graph will not rescue them. When retrieval fails on a corpus it is usually because the content does not contain the answer, and no amount of infrastructure fixes that. Finding that out in an afternoon on a free tier is a good outcome — it is a content problem, and now you know.