VectorAI DB Doesn't Embed Your Text, and That's the Point

Building a small local knowledge base on top of Actian VectorAI DB, the actual challenge wasn't the database. It was easy to accidentally fake semantic search, and just as easy to reach for automation tools, or an LLM, in the wrong place. Here's the split that fixed it, plus the grounded answer step I added on top of search. The full build is on GitHub.

Two ways to fake it

The first pass at this stored a single note and searched for that same note. It "worked," in the sense that the top result was always right. That doesn't prove anything about semantic search: with one point in the database, of course it wins.

The other early version chained four n8n HTTP Request nodes straight into the database. That's not using n8n for anything; it's a curl command dressed up as a workflow.

Both come from the same mistake: not being clear on what each tool is actually for.

Once that's the frame, the fix is straightforward: give the embedding model a real corpus, let VectorAI DB just be the store, and only bring n8n in as a trigger.

Proving search actually works

Six notes: five on-topic, one deliberate distractor about campus cafe hours. If a search demo can't tell "how do I start the database" from "what does the cafe serve," it isn't doing much. Real queries against the running container:

No cafe question beat a Docker or pricing question. These scores are cosine similarity, not percentages: treat 0.466 as "clearly the best match among the options," not "47% confident."

A brand-new note, added through the UI and searched for right away, also came back correctly. VectorAI DB's upsert blocks until the point is indexed by default, so that's a real upsert-then-retrieve, not a cached result.

The split, in practice

The embedding model does the language understanding, not the database. VectorAI DB never sees a search string; every insert and every search is a float array, and its length has to match whatever size the collection was created with:

PUT /collections/kb
Content-Type: application/json

{"vectors":{"size":384,"distance":"Cosine"}}

Get the dimension wrong and it says so plainly:

Upsert failed: Dimension mismatch for vector '': expected 1536, got 3

That error shows up fast if you swap embedding models without recreating the collection.

The payload holds the human-readable text. Each vector carries a title and text alongside it, so a search result comes back readable, not just an ID and a score to look up elsewhere.

n8n only makes sense as a trigger. What's actually built is three nodes: a webhook, an HTTP call to the app's /api/search, and a response back. On its own, that's not doing much more than curl.

The value shows up when the trigger changes and nothing else does. Swap the webhook for a Slack trigger or a form submission, and the same search logic still runs; only the front door changes. The Slack version isn't built for this demo, so there's nothing to show running yet, but that's the actual case for n8n here: it makes adding a second or third way to trigger the same search cheap.

Adding a grounded answer

Ranked hits are still excerpts, and most people want a sentence, not a list. /api/answer reuses the exact same search, then hands the top few excerpts to an LLM with one rule: answer only from what search returned, and say the knowledge base doesn't cover it rather than guess.

Worth being precise about what this is and isn't. VectorAI DB still only ever sees float vectors; it has no idea an LLM exists. The app calls search, gets back title/text payloads, and only those payloads go into the prompt, never the vectors, never anything outside them. Without an API key, the endpoint doesn't error; it returns the same ranked hits with "answer": null, so the base demo has zero dependency on an LLM being available.

The check that mattered: asking something the seeded notes don't cover, or a cafe question when the answer should come from the database, and confirming the model says it can't find that rather than inventing something plausible-sounding. If retrieval is wrong or the corpus doesn't have the answer, generation shouldn't be able to paper over that.

What the pattern generalizes to

The six-note demo is a stand-in. Swapping in a different corpus doesn't touch the plumbing:

• A team FAQ or handbook, searched from Slack instead of a browser tab.
• Support tickets, where the payload is the past resolution instead of a note body.
• A product catalog or pricing sheet, so "what's included in the Pro tier" finds the right snippet even if it's worded differently.
• Agent memory: chat turns as points, search before answering.
• Grounded answers on any of the above: /api/answer already does this for the six-note demo, and the same prompt-and-refuse pattern carries over.

Different corpus, sometimes a different trigger. Same architecture.

One gotcha worth knowing

Each point's ID is a hash of the note's text, so re-saving a note with the same wording overwrites the same point. Edit the wording, even slightly, and it's treated as a new point: the old version doesn't get cleaned up, it just sits there, still searchable, still a possible top result. Decide early whether edits should replace or version, and delete the stale point explicitly if you want replace.

This is small and local on purpose. It hasn't been pushed anywhere near the 5,000-vector ceiling on Community Edition, and there's no auth or TLS in front of it, so it's not production-ready as-is. Fork the repo, swap the corpus, pick a trigger, and the pattern holds.