Search your own documents with AI without uploading them: scoped RAG, explained
Every document search built on AI has the same weakness: the more you feed it, the worse it gets at finding one thing. Filer's answer is not a bigger index — it is the folder you are already standing in.
Published September 10, 2026 · 6 min read
You have a few thousand files on a work drive — contracts, meeting notes, spreadsheets, a decade of drafts. You want to ask a question of them the way you would ask a colleague who has read them all. The usual route is to upload them somewhere: a chat product with a knowledge base, a note app with an AI tab, a vendor's document workspace. That route works, and it costs you the one thing about those files that was never negotiable — they leave.
There is a second way that gets much less attention, and it is not a privacy compromise: keep the files where they are, and make the search understand where you are looking. That is what Filer does, and this post is about the mechanism — what it is, why the narrowing matters more than the model, and exactly where the honest limits are.
What RAG actually does
RAG — retrieval-augmented generation — is a plain idea wrapped in an acronym. A language model has no memory of your files. So before it answers, something goes and finds the few passages from your documents that look relevant to the question, and hands only those to the model along with the question. The model answers from what it was handed. Retrieval first, generation second. That is the whole shape.
The finding step works on meaning, not on exact words. Each passage of each document is turned into a list of numbers — an embedding — that positions it by what it is about, so a question about "the renewal deadline" can surface a paragraph that only ever says "the agreement expires on." Filer builds those embeddings when you memorize a file, and keeps them in that folder's own index. Memorizing is something you do deliberately, file by file or folder by folder — nothing on your disk is read into an index because it happened to be there.
Why a smaller scope beats a bigger index
Here is the part that surprises people: retrieval quality does not improve as you add documents. It degrades. Every document you add is another candidate that can score plausibly against a question it has nothing to do with — last year's version of the same contract, a template that shares all the vocabulary, a status report that mentions the topic once in passing. The right passage does not get worse; it just gets harder to pick out of a bigger pile of near-misses.
This is why AI document products so often cap what you can put in one workspace — a few dozen files, a single project — and why the cap reads as a limitation when it is actually a quality control. Precision is the scarce resource, not capacity.
Which suggests an obvious fix that almost nothing does: instead of capping how much you can keep, narrow what any one question is allowed to look at. If a question could only ever be answered from the eleven files in project-alpha/design/, then the other four thousand files cannot compete for the answer — not because they were ranked lower, but because they were never candidates.
The catch is that someone has to say what the scope is, and asking a person to define scopes is asking them to do filing work twice.
The folder you are standing in is the scope
Except you already did that work. A folder tree is a scope hierarchy — it is the one you built, by hand, over years, according to how you actually think about your own work. Filer just reads it that way: the folder you are currently in is the search scope, and everything memorized beneath it is what a question can reach.
D:/work/ ← broad — every project
├── project-alpha/ ← narrower — just this project
│ ├── design/ ← precise — design docs only
│ └── reports/ ← precise — reports only
└── project-beta/Ask from work/ and the question reaches everything; ask the same question from project-alpha/design/ and it reaches eleven files. You did not configure a scope, name a collection, or tag anything. You navigated — the same way you navigate to open a file — and the search narrowed with you. Going back up widens it again.
Both places you can ask work this way. The chat panel in Explorer is scoped to the folder in view, and the AI Search screen shows the scope above the search box, where you can edit it directly if you want to search somewhere other than where you are standing. It is the same mechanism underneath: the folder path decides which memorized passages are eligible.
Scope for search is not the same thing as the security boundary
The default is a heuristic, and it is worth being straight about that: if you filed something in a place your question does not cover, a folder-scoped search will miss it. That is the cost of a default that requires no setup, and the fix is one click up the tree. For the cases where you want the whole picture on purpose — "which of my folders has anything about this?" — asking from the root is exactly that.
Where the embedding actually runs
The title of this post says "without uploading them," so it should say precisely what that does and does not mean.
Filer does not ship a model and does not require a subscription. You choose where inference happens, under Settings → AI:
- A local model. Embedding and chat both run on your machine. Your documents are read from disk, turned into embeddings on the same box, and stored in that folder's index next to the files. Nothing about their content goes out over the network. This is the configuration the title describes literally.
- Your own cloud API key. Filer talks to a provider you already pay for, with your key.
- Your company's own server. GPUStack, Ollama, vLLM, or any OpenAI-compatible endpoint your organization already runs — the same connection, pointed inside your network instead of out of it.
In the second and third cases, the passages retrieved for a question travel to that endpoint, because that is where the model that answers lives. Folder scope changes which passages go, not whether they go. That is still a meaningful reduction — a question answered from one subfolder sends a handful of passages instead of your whole library, and the files themselves are never uploaded or copied anywhere — but it is not the same claim as "nothing leaves this machine," and only the local option makes that stronger claim true.
For most people at work the third option is the interesting one, because the endpoint is already inside the boundary their employer cares about. That case has its own post: using your company's AI server from your own desktop.
What it looks like day to day
In practice the scoping stops being a feature you think about and becomes a reflex — the same reflex you already have about where to look for a file.
- Standing in a project folder, asking about the project. You are in
project-alpha/because that is what you are working on; the question inherits it. No preamble telling the AI which project you mean. - Going one level deeper to cut the noise. If an answer pulled in something from
reports/when you wanted the design decision, move intodesign/and ask again. Narrowing is navigation, not a settings change. - Going up when you genuinely want breadth. "Have I written anything about this before?" is a root-level question, and asking it from the root is how you get it.
Three usecases show the shape end to end: building a searchable index of a folder is the starting move; asking questions of data files is the same retrieval applied to spreadsheets and exports; finding your own earlier draft is the breadth case, where you widen on purpose because you do not remember where you filed it.
None of this makes the model smarter. It makes the question easier — and for finding one document among thousands, that turns out to be the half that was actually broken.