Why BunnyQuery is not built on a vector database

Almost every AI-that-reads-your-files product cuts your documents into fragments, turns each fragment into a vector, and hands the model whichever fragments look closest to your question. Your Bunny does not work that way, and the reason is worth explaining.

How everyone else does it

The standard recipe has four steps. Chop each document into chunks of a few hundred words. Run every chunk through an embedding model, which turns it into a long list of numbers that encodes roughly what the chunk is about. Store those numbers in a vector database. When a question arrives, turn the question into numbers the same way and return the handful of chunks whose numbers sit closest to it.

This is what people mean when they say RAG, and it is what a vector database is for. It became the default for good reasons: ingesting is almost free, it works genuinely well on flowing prose, and you can wire it up in an afternoon.

It also has a failure mode that nobody talks about in the demo.

The question it cannot answer

Say you upload a year of supplier paperwork. Sixty invoices, some as PDFs from email, some photographed, a few buried in a spreadsheet your card company exported. Then you ask the obvious question.

How much did I spend with this supplier last year?

A similarity search returns the closest chunks. Maybe eight of them. The model adds up the numbers it can see and gives you a total, in a confident sentence, with no hedging.

That total is wrong. It is missing fifty-two invoices.

Nothing in that system knows it is wrong. Similarity search has no concept of "all of them." It returns the closest few, always, whether the right answer was three documents or three hundred, and it never reports what it left behind. There is no setting for completeness, because there is nothing in the design that could implement one.

Now notice how many real questions have this shape. How many. What is the total. Which one is the cheapest. Is there any record of this. Do we have none of these. That is most of what anyone actually asks about their own business data, and it is precisely the category that fragment retrieval cannot answer honestly.

What your Bunny does instead

When you upload a file, it gets read. Not sampled, not chunked and filed away. An AI model reads it end to end, and writes down what is in it as structured records.

• A spreadsheet becomes one record per row, with every value stored under its real column header.
• A book becomes one record per chapter, with its characters, places and topics tagged.
• A scanned form becomes the characters actually read off it, typed and handwritten, in their own fields.
• A photo embedded inside a spreadsheet is pulled out as its own permanent file, tagged with what it shows and with the exact cell it was sitting next to.

Big files are still read in windows, because a 200 MB spreadsheet does not fit in anyone's context. The difference is what survives that pass. We keep the extracted records. The fragments are scaffolding, and they are thrown away.

So a price stays a number, not a word inside a sentence. A part number like 500.7402.52 is stored as those exact characters. Every record carries a link back to the file it came from, which is how your Bunny can pull up an entire document's worth of data in a single lookup no matter how it got split up.

The understanding happens when the file arrives. By the time you ask something, the answer is a query, not a guess.

What that gets you

It can say "all," and it can say "none." Your Bunny can page through a complete result set and know when it has reached the end. So "there are no invoices from that supplier" is a real answer backed by a real scan, instead of a shrug dressed up as a sentence.

Totals are arithmetic, not estimation. Counts, sums and averages are maintained as your data lands, so "what did I spend" is a lookup of a number that was already correct. It is not the model adding up whatever fragments it happened to be shown.

Identifiers come back exactly right. 500.7402.52 and 500.7402.53 are nearly identical as vectors, and similarity search confuses them constantly. Stored as exact values, they cannot be mixed up. The same goes for serial numbers, invoice numbers, and the last four digits of a card.

Ranges and sorting actually work. Orders over 500. Everything between March and June. The three most expensive. These need numbers that are still numbers, and dates that are still dates.

The same question gives the same answer tomorrow. Change an embedding model and what is findable silently changes, with no warning and nothing to review. Extracted records are stable. Nothing shifts under you because a vendor shipped a new model.

You can check its work. This is the one we would point at first. Open your Files page and look at the records your Bunny made from a document. You can see exactly what it read out of row 412 and compare it against the original. Nobody can inspect an embedding and tell whether it is going to work. When something looks off, you can find out why.

Your permissions are real. Access rules are applied by the database before results exist, not by trimming a list of matches afterward. Private records are masked, and collaborators see what they are allowed to see.

You can correct it. If a row came out wrong, tell your Bunny to fix it and the fix is live for the next question. In a vector setup the index is a derived artifact, so fixing one fact means rebuilding it.

What this costs, honestly

Reading every file properly is far more expensive than turning it into vectors, in both time and API budget. That is why indexing a large document takes minutes rather than seconds, and why we show you a status row while it happens instead of pretending it is instant.

We think it is the right trade, because you upload a file once and then ask questions about it for a year. Paying at upload to be right for a year is a better deal than paying nothing at upload and being quietly wrong forever.

There is one thing the other approach genuinely does better, and we would rather say it than have you discover it. Similarity search is good at loose recall over long prose. If you cannot remember a single word, name or number that appears in a document, and you can only describe the gist of it, embeddings will find it and we might not. We tag heavily at index time to close as much of that gap as we can, and it is a real gap.

We would rather be exactly right about your invoices than approximately right about everything.

So is this RAG or not?

Technically, it is. RAG names a pattern: fetch information from outside the model and answer from it rather than from memory. It does not say how to fetch. Vector search is one way to do the fetching. It became so dominant that people started using "RAG" to mean that one recipe, but SQL, keyword search and plain lookups are all equally valid ways to do the R.

What your Bunny does has a more precise name: structured extraction with agentic retrieval. Extraction, because your files become typed records instead of fragments. Agentic, because the model writes its own queries, reads the results, notices what is missing, and queries again, rather than being handed a fixed pile of chunks that some pipeline picked before it ever saw your question.

You can take it with you

Because your data comes out as records rather than vectors, it is not trapped. Every BunnyQuery project is a full Skapi service, so the same extracted records are readable from your own code, exportable as a CSV, and reachable over MCP from any MCP-compatible AI client.

Embeddings are not portable and not human-readable. They are a lock-in format by accident: a few million floating point numbers that mean nothing outside the model that produced them. Extracted records are just your data, organized. If you ever leave, you take it with you.

Go ask your Bunny something that needs a real number.

Baksa, Creator of BunnyQuery