Why "Local RAG chunk size starting points" matters for local RAG
Start with 400–800 tokens and 10–20% overlap; evaluate on your own PDFs, not leaderboards. Retrieval-augmented generation is usually the first serious project a team builds on a local model, because it keeps documents in-house and avoids fine-tuning. It is also where small design choices decide whether people trust the answers.
Ingestion comes first
Bad input produces confident wrong answers. Before thinking about embeddings:
- Extract structure: headings, tables and lists should survive conversion from PDF or Office files.
- Attach metadata to every chunk: source file, section, version and document date.
- Reject documents that have no owner or no date; stale policies are a liability.
- Keep the original files so you can re-ingest when your splitter improves.
Chunking and retrieval
Start with moderate chunk sizes and some overlap, then evaluate on your own questions instead of copying settings from a blog. Chinese text needs a splitter that respects sentences rather than English whitespace rules. Pure vector search misses exact identifiers such as part numbers, contract IDs or SKUs, so keep a keyword index alongside the vector store and merge the results. When policies change over time, bias retrieval toward the newest valid version.
Evaluation you can repeat
Build a set of real questions with known answers and the documents that should support them. After each change to chunking, embedding model or prompt, run the set and look at both the answer and the retrieved passages. If the right passage was not retrieved, no prompt will fix it.
Operations
- Back up the vector store and test a restore.
- Separate collections per department or client so access rules are easy to enforce.
- Log which sources were cited for each answer.
- Decide what the assistant must refuse to answer, and publish that list.
Questions for your pilot users
- Did the answer cite the document you expected, and was it the current version?
- Was anything important missing that you know exists in the documents?
- Did the assistant refuse when it should have, and answer when it should have?
- How long did it take to verify the answer using the cited source?
Collect these answers in a simple form during the pilot. Patterns in the feedback usually point to ingestion or retrieval problems, which are cheaper to fix than switching models.
For related guides, see local AI tutorials; you may also find local RAG knowledge-base guide useful.
Bottom line
Local AI rewards patience and record keeping more than raw spending. Decide what the system must do, measure it on your own hardware and documents, write down every change with a date and an owner, and review the setup after each significant upgrade. Small, documented steps are easier to debug, easier to hand over and easier to defend when someone asks why a particular choice was made. When in doubt, test on a smaller scale first and expand only when the evidence supports it.
Quick reminders
- Leave memory headroom for the OS and the embedding model.
- Write the date and owner on every change record.
- Measure on your own prompts before quoting any speed.
- Keep a printed fallback for offline demos.
Published by MicroAI One (本地AI 1号网), a Shenzhen team working on local LLM hardware, software and deployment.