When to re-embed, and why nobody scheduled it

Ask a team who owns re-embedding their knowledge base and you usually get a pause. The documents have owners. The model has owners. The job that keeps the two in sync belongs to nobody, so it happens never.

A job with no home

Re-embedding is not hard. It is unowned. When you build a RAG system, embedding the corpus is a one-time task inside the launch, so it gets done and checked off. Then the system goes live and the corpus keeps moving. New documents arrive. Old ones get edited. Some get deleted. Every one of those changes should trigger an embedding update, and none of them do, because the update was scoped as a launch step and never as a standing responsibility.

I saw this play out the way most ownership gaps do. The content team edits documents all day and assumes the AI picks up their changes, the way a website would. The engineering team built the index months ago and assumes the content is static, because it was static the week they built it. Nobody is wrong about their own job. The job that connects them, noticing a document changed and re-embedding it, sits in the space between two teams and gets done by neither.

The question that should be asked at design time

An engineering leader who runs infrastructure at a large platform has a habit worth borrowing. He wants the question “who gets paged when this misbehaves” answered during design, not during the incident. Re-embedding needs the same treatment. Who owns the freshness of the index? What event triggers a re-embed? How stale is too stale before someone acts? If those questions do not have answers before launch, the default answer is silence, and silence means the vectors drift away from the documents until a user hits the gap.

When to actually do it

There is no single schedule that fits every corpus, because the right cadence depends on how fast your content moves. A few triggers cover most cases. Re-embed a document when it is edited, ideally as part of the same workflow that saved the edit, so freshness is automatic rather than remembered. Re-embed on a rolling schedule for slow-changing corpora, so even untracked edits get caught within a known window. Re-embed the whole corpus when the thing underneath changes, a new embedding model or a new chunking strategy, because mixing vectors from two different models in one index quietly poisons the rankings.

The point is that each of these is a decision someone has to own and put on a calendar. Left to good intentions, re-embedding loses every time to work that has a deadline and a name attached.

Drift is the cost of the missing schedule

The reason this matters is that the gap does not stay small. Every unembedded edit widens the distance between what the documents say and what the index encodes. For a while the system still answers most questions well, so nothing looks wrong. Then it crosses the line where enough answers are grounded in outdated chunks that users stop trusting it, and by then the drift has been accumulating for months with no owner watching it. The fix is not a smarter model. It is a scheduled job and a name next to it.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two week, $2,500 engagement, we ask who owns index freshness and what triggers a re-embed, the same way we ask who gets paged when a pipeline goes quiet. If the answer is nobody, that is the finding. We help define the triggers, the cadence, and the single named owner, so re-embedding becomes a scheduled responsibility instead of a task that everyone assumes someone else is doing.

A recurring job with no owner is not recurring. It is a one-time job you did once and stopped.