I had a refund note that said 14 days. I copied that sentence into a second file and treated the copy as the search index, the frozen text a question would read later. Then I changed the note to 30 days. The file on disk said 30. The copy still said 14. That gap is what people hit when they answer questions from their own documents, a setup called RAG (answers from your files, not memory). So does serviette update when files change? It is a server built to watch the folder and refresh that copy when a file changes. My demo did not get there. The first command stopped and asked for a free license key.
How do I keep RAG updated when files change?
Keep the search copy tied to the file, and refresh the piece that changed, instead of trusting a full rebuild you ran earlier.
A chat program does not open your folder by itself. It only knows the text you put in front of it. If you paste a whole handbook into the chat every time someone asks a question, the chat fills up and the bill climbs. People avoid that by making a smaller copy they can search.
The copy is not the sentence. A computer does not know that “money back” and “refund” are the same idea unless you turn each short piece of text into a list of numbers that sit near similar ideas. That list is an embedding (numbers that stand for a sentence). A vector database is a store built to find nearby lists, not just an exact word. The short piece itself is a chunk: one slice of a file, because a whole handbook is too big to turn into one list.
None of that stays true on its own. You compute the lists once. Someone edits the handbook. The lists still describe the old sentences. The question gets a confident answer from a world that already ended. Keeping RAG updated means noticing the edit, the new file, or the delete, and changing only those lists.
Why does a saved index go stale?
A saved index goes stale because it is a copy taken at one moment, and the file can change after that moment.
I made a folder and put one file in it, policy.md. The first line was “Refunds are allowed for 14 days after delivery.” I copied the whole file into snapshot_index.txt. That copy is the same shape as an index you build at night and then leave alone. I then replaced “14 days” with “30 days” in policy.md and did not touch the snapshot.
The file’s first line was “Refunds are allowed for 30 days after delivery.” The snapshot’s first line was still “Refunds are allowed for 14 days after delivery.” A read of the live file, the kind you do at the moment of the question, returned 30 days. The truth had been on disk the whole time. The search copy was the thing that lied. The file was 138 bytes. Size was not the problem. Age of the copy was.
This is in contrast to opening the file again for every question. A live read cannot go stale, and it also does not scale. You would hand the model every page, every time. The index exists so you can hand it a few pieces. The price of that shortcut is that the pieces must be replaced when the source moves.
Does serviette update when files change?
Serviette is built to update when files change, and the demo will not start until a Pathway license key is set.
I installed the serviette package and ran serviette demo with no key in the environment. It exited at once and printed this line: “serviette demo needs a Pathway license key (free, one click at https://pathway.com/framework/get-license). Set PATHWAY_LICENSE_KEY and re-run.” No answer changed, because there was no answer yet.
What the program is built to do is still the right shape for the 14-day bug. One process, the indexer, watches the folder. It reads the file, cuts it into chunks, turns each chunk into an embedding, and writes those lists into a database. An edit becomes a replacement of the old lists. A new file becomes new lists. A delete becomes a removal, so a ghost sentence cannot keep winning the search. A second process, the server, only reads that database and answers from whatever is there now. The two processes do not talk to each other. If the indexer is down, the server still answers from the last lists it can see. If the server is down, the indexer can keep writing. Freshness and uptime are split on purpose.
The default database is DuckDB, one file on the machine, with no separate database server to install. The project also ships a short recording of a chat answer changing after a one-line edit. That recording is theirs. My run stopped at the key.
Serviette vs rebuilding the index
Rebuilding the whole index on a schedule works, and it is the wrong default once people edit the folder during the day.
A nightly job would have fixed my refund note at the next run. Until that run, every question would still hear 14 days. If the job only adds files and never deletes, a removed page can stay in the index and get cited. Serviette’s indexer is the attempt to make the edit, the add, and the delete land in the database without waiting for a person to remember the script.
| Nightly rebuild | Serviette | |
|---|---|---|
| File edited | Old text until the job runs | Indexer is built to replace that file’s chunks |
| File deleted | Old chunks can remain | Indexer is built to delete them |
| What you run | A script you must remember | A config file and two processes |
| First stop | Whatever your script needs | A free Pathway license key |
| One laptop | Fine | DuckDB, one file, one writer |
| Remembered chat | Your app’s problem | Not built in. One question at a time |
Pick the rebuild when the folder is almost still. A handbook you touch twice a year does not need a watcher sitting on it. Pick serviette when the note can change while people are still asking questions about it, and you can stand a license key and a process that stays up.
This is a different choice from how you search inside one long file. If the page is stable and the hard part is finding the right section, that problem is pageindex vs vector database. This page is about the section changing after you stored it. It is also different from shrinking a chat so the old instructions fit. Storing the file, or squeezing the conversation, is the split in context mode vs compact. And if the job is finding a function by what it does, rather than keeping a policy note fresh, that search is xerj vs grep.
How do I run serviette on my own folder?
Upgrade pip if it is older than 23.1, set the free license key, then point serviette at the folder.
My first install used pip 23.0.1. It sat with an empty log. The project warns that an older pip cannot resolve this dependency tree well. I stopped that install, upgraded pip, and the same pip install serviette finished. Start there if the installer looks frozen.
python -m pip install -U pip
pip install serviette
export PATHWAY_LICENSE_KEY=...
serviette wizard
serviette up --config config.yamlThe wizard writes the config. serviette up runs the indexer and the server together. The chat page and the API share one port, http://localhost:8989. A retrieve call looks like this:
curl -X POST http://localhost:8989/api/v1/retrieve \
-H 'Content-Type: application/json' \
-d '{"query": "how long is the refund window?", "k": 5}'Two keys are easy to mix up. The Pathway key is required. The command I ran refused to start without it. You get that key from the Pathway license page with a GitHub or LinkedIn sign-in. The other key, for a model that writes the answer paragraph, is optional. Leave it unset and the server is meant to quote the retrieved snippets instead of composing a paragraph. That is the mode I would use first, because a quote is easier to check against the file.
If you do not want the document text sent out to make embeddings, install the local extra instead of the plain package. It pulls a CPU build of the library that computes embeddings on your machine:
pip install "serviette[local]" --extra-index-url https://download.pytorch.org/whl/cpuAn API embedder sends the document text to that provider. A local embedder keeps the documents and the lists on the machine you chose. If you later turn on an answer model, the passages used for that one question still leave, because the model has to see them. The index itself does not have to.
The source and the commands live in the serviette repository.
When should I not use serviette?
Do not use serviette if you need a remembered conversation, several writers on one DuckDB file, or a search that must run before you can get a license key.
The server answers one question at a time from the current documents. Conversation memory, user accounts, and a hosted product are not built in. If you need the next question to remember the last one, you have to add that outside this program.
DuckDB is the easy default and it is single-writer. One indexer, one file, a laptop: that matches the demo. Two indexers writing the same file will fight. If the indexer and the server must live on different machines, pick another database the config already knows: pgvector, Qdrant, Milvus, Chroma, Weaviate, Pinecone, or MongoDB. Pinecone is the odd one. It cannot list documents the way the others can, and the keyword-plus-numbers search is not offered there. I would not start on Pinecone.
A folder that rarely changes does not pay you back for a live watcher. Run a rebuild when you publish the handbook, check that deleted pages are gone, and stop. A watcher you forget to restart is a second way to go stale, quieter than a job you can see on a clock.
One more trap sits in the name. Serviette is also the ordinary word for a napkin. A search for the word alone will not find this server. Search the name with RAG, or open the repository, or you will be reading about table linen.
Common questions about serviette
Can I run serviette without sending documents to an API?
Yes. Use the local embedder and do not set a key for the answer model. You still need the Pathway license key. The answers are quotes from the files, which is what you want while you are checking that an edit actually landed.
Does deleting a file remove the old answer?
The indexer is built to turn a delete in the folder into a delete in the database. My run stopped at the license key before I could watch that happen. A rebuild script that only adds files will not do this. It leaves the old chunks in place, and those chunks can still win.
Is DuckDB enough or do I need another database?
DuckDB is enough for one person and one machine. It is one file and one writer, which is why the default needs nothing else installed. Move to another database from the list when a second machine has to write, or when the server should stay up on a different box from the indexer.
What if the indexer stops?
The server keeps answering from the last lists in the database. New edits wait. Search stays up, and freshness pauses, until the indexer is back. That split is useful. It is also how a folder can drift again if nobody notices the indexer is dead.
Should you turn serviette on?
I would turn this on for a folder people edit during the week, after the license key is in the environment and after I have seen one edited line show up in a quote. I would leave a quiet handbook on a rebuild I run myself. The 14-day copy is still in my test folder, wrong, and nothing fixes it until something reads the file again.
