AI personal knowledge base: RAG over a personal text file

Updated: October 29, 2026

An AI personal knowledge base can be built around one text file: it has dates, notes, tasks, and context. For small archives, search and manual context are enough. RAG becomes useful when the file gets large or when you want to automate search and answers with citations.

When plain search is enough

Start simple. Find the relevant entries with rg or grep, pass a few fragments to the model, and ask your question. For a file of a few hundred kilobytes, this is often enough.

rg -n "project X|TODO|Idea" everything.txt | head -40

RAG makes sense when the file does not fit in context, when you need answers across hundreds of documents, or when search must run automatically on every request. For ten notes, a complex system costs more than manual search.

How RAG works

The pipeline is simple: split the text into chunks, build a vector representation for each chunk, store the vectors, then retrieve the closest chunks for a question and pass them to the model.

1. Split the file into fragments.
2. Build embeddings for each fragment.
3. Store vectors and metadata.
4. Find the closest fragments for the question.
5. Pass the fragments to the model and ask for an answer with citations.

The last step matters. The model should answer from the retrieved fragments, not from its own memory. Otherwise you get a polished answer that is not grounded in your notes.

How to split OBTF

Do not cut the file at random characters. Split it by meaning: dates, headings, or entry blocks. A fragment can contain a few paragraphs or up to a page of text.

• Keep the date and source in metadata.
• Add a small overlap between neighboring chunks so context is not lost at the boundary.
• Do not mix different projects in one fragment if they can be separated.
• For paper notes, keep the page number and a link to the scan.

Metadata matters more than chunk size. If the model knows the date and source, the answer can be checked. If it does not, a citation becomes a guess.

Embeddings and storage

An embedding turns a text fragment into a set of numbers. Fragments with similar meaning end up close together in vector space. For Russian and English text, models such as nomic-embed-text, bge-m3, and other multilingual options work well.

For storage, use Chroma, LanceDB, or sqlite-vec. A small personal archive can also work with a simple vector file, but a proper store saves time.

The local option

If data must stay on your machine, use local models. Ollama can run both a generative model and an embedding model.

ollama pull llama3.1
ollama pull nomic-embed-text
ollama run llama3.1

You still need a small script. It reads the file, splits it into chunks, gets embeddings, stores them, and retrieves the closest entries. You can write it in Python or another language you know. The important part is to keep metadata and preserve the original text.

A local setup is slower than a cloud one, but more private. For sensitive notes, that trade is often worth it.

External models

External models are easier to set up and usually stronger. But the text leaves your machine. Do not send passwords, keys, or third-party personal data. Check the provider's retention and training settings where available.

For a cloud setup, you can use a model API and a separate embedding service. The workflow is the same: retrieve fragments, pass them to the model, and get an answer with references to dates and entries.

Prompts with citations

A good prompt requires grounding in the text. Examples:

• “Answer only from the provided fragments. For every claim, cite the date and source.”
• “Find open tasks for project X. Return the date, task, and next step.”
• “Compare decisions on topic Y over the last six months. Show what changed.”
• “If the answer is not in the text, say so. Do not invent facts.”

After the answer, check the citations against the file. A model can confuse dates, merge two fragments, or add a conclusion that was never there.

Privacy and security

The index contains the same data as the source file. If the file is encrypted, the index needs protection too. Do not store embeddings in the open if the notes contain sensitive information.

For a local setup, keep models and the index on your disk. For a cloud setup, review who has access to the account and enable two-factor authentication. For more on encryption, read the separate guide.

Limitations

• The index goes stale after major edits and must be rebuilt.
• Handwriting recognition can add errors to the knowledge base.
• A model can invent a fact even when the right fragments were retrieved.
• A large index needs memory and search time.
• Metadata can be lost with poor chunking.
• RAG does not replace backups or source checks.

Checklist

• It is clear why RAG is needed instead of plain search.
• The file is split by meaning, with dates and sources.
• Embeddings and the index are protected like the original notes.
• The model is instructed to answer from the text and cite sources.
• Answers are checked against OBTF and scans.
• There is a plan to rebuild the index after major changes.

If you are still choosing between plain search and RAG, start with search using grep and rg. If you want to connect a paper notebook to models, read the guide on notebooks, OBTF, and LLMs.