All models tested with ALLM(AnythingLLM) with LM-Studio as server, all models should be work with ollama

the setup for local documents described below is allmost the same, GPT4All has only one model (nomic), and koboldcpp is not build in right now

(sometimes the results are more truthful if the “chat with document only” option is used)
BTW embedder is only a part of a good RAG
⇨ give me a ❤️, if you like ;)

My short impression:

nomic-embed-text (up to 2048t context length)
mxbai-embed-large
mug-b-1.6
snowflake-arctic-embed-l-v2.0 (up to 8192t context length)
Ger-RAG-BGE-M3 (german, up to 8192t context length)
german-roberta
bge-m3 (up to 8192t context length)

Working well, all other its up to you! Some models are very similar! (jina and qwen based not yet supported by LM)
With the same setting, these embedders found same 6-7 snippets out of 10 from a book. This means that only 3-4 snippets were different, but I didn't test it extensively.

...

Short hints for using (Example for a large context with many expected hits):

Set your (Max Tokens)context-lenght 16000t main-model, set your embedder-model (Max Embedding Chunk Length) 1024t,set (Max Context Snippets) 14, in ALLM set also (Text splitting & Chunking Preferences - Text Chunk Size) 1024 character parts and (Search Preference) "accuracy".

-> Ok what that mean!
Your document will be embedd in x times 1024t chunks(snippets),
You can receive 14-snippets a 1024t (~14000t) from your document ~10000words and ~2000t left (from 16000t) for the answer ~1000words (2 pages)
You can play and set for your needs, eg 8-snippets a 2048t, or 28-snippets a 512t ... (every time you change the chunk-length the document must be embedd again)

8000t (~6000words) ~0.8GB VRAM usage
16000t (~12000words) ~1.5GB VRAM usage
32000t (~24000words) ~3GB VRAM usage

here is a tokenizer calculator
https://quizgecko.com/tools/token-counter
and a Vram calculator - (you need the original model link NOT the GGUF)
https://huggingface.co/spaces/NyxKrage/LLM-Model-VRAM-Calculator

...

How embedding and search works:

You have a txt/pdf file maybe 90000words(~300pages) a book. You ask the model lets say "what is described in chapter called XYZ in relation to person ZYX". Now it searches for keywords or similar semantic terms in the document. if it has found them, lets say word and meaning around “XYZ and ZYX” , now a piece of text 1024token around this word “XYZ/ZYX” is cut out at this point. (In reality, it's all done with coded numbers, but dosnt matter - the principle)
This text snippet is then used for your answer.

If, for example, the word “XYZ” occurs 100 times in one file, not all 100 are found.
If only one snippet corresponds to your question all other snippets can negatively influence your answer because they do not fit the topic (usually 4 to 32 snippet are fine)
If you expect multible search results in your docs try 16-snippets or more, if you expect only 2 than dont use more!
If you use chunk-length ~1024t you receive more content, if you use ~256t you receive more facts BUT lower chunk-length are more chunks and need much longer time.
A question for "summary of the document" is most time not useful, if the document has an introduction or summaries its searching there if you have luck.
If a book has a table of contents or a bibliography, I would delete these pages as they often contain relevant search terms but do not help answer your question.
If the documents small like 10-20 Pages, its better you copy the whole text inside the prompt, some options called "pin".

...

Nevertheless, the main model is also important!

Especially to deal with the context length and I don't mean just the theoretical number you can set. Some models can handle 128k or 1M tokens, but even with 16k or 32k input the response with the same snippets as input is worse than with other well developed models.

...

Important -> The Systemprompt (some examples):

The system prompt is weighted with a certain amount of influence around your question. You can easily test it once without or with a nonsensical system prompt.

"You are a helpful assistant who provides an overview of ... under the aspects of ... . You use attached excerpts from the collection to generate your answers! Weight each individual excerpt in order, with the most important excerpts at the top and the less important ones further down. The context of the entire article should not be given too much weight.
Answer the user's question!
After your answer, briefly explain why you included excerpts (1 to X) in your response and justify briefly if you considered some of them unimportant!"
(change it for your needs, this example works well when I consult a book about a person and a term related to them, the explanation part was just a test for myself)

or:

"You are an imaginative storyteller who crafts compelling narratives with depth, creativity, and coherence. Your goal is to develop rich, engaging stories that captivate readers, staying true to the themes, tone, and style appropriate for the given prompt. You use attached excerpts from the collection to generate your answers! When generating stories, ensure the coherence in characters, setting, and plot progression. Be creative and introduce imaginative twists and unique perspectives."

or:

"You are are a warm and engaging companion who loves to talk about cooking, recipes and the joy of food. Your aim is to share delicious recipes, cooking tips and the stories behind different cultures in a personal, welcoming and knowledgeable way."

...

usual models works well:

llama3.1, llama3.2, qwen2.5, deepseek-r1-distill, gemma-3, granite, SauerkrautLM-Nemo(german) ...
(llama3 or phi3.5 are not working well)

⇨ best models for english and german:
granit3.2-8b (2b version also) - https://huggingface.co/ibm-research/granite-3.2-8b-instruct-GGUF
Chocolatine-2-14B (other versions also) - https://huggingface.co/mradermacher/Chocolatine-2-14B-Instruct-DPO-v2.0b11-GGUF
QwQ-LCoT- (7/14b) - https://huggingface.co/mradermacher/QwQ-LCoT-14B-Conversational-GGUF

btw. Jinja templates very new ... the usual templates with usual models are fine, but merged models have a lot of optimization potential (but dont ask me iam not a coder)

...

DOC/PDF 2 TXT

Prepare your documents by yourself!
Bad Input = bad Output!
In most cases, it is not immediately obvious how the document is made available to the embedder. in nearly all cases images and tables, page-numbers, chapters and sections/paragraph-format not well implement. An easy start is to use a python based pdf-parser (it give a lot).
option only for simple txt/tables converting:

pdfplumber
fitz/PyMuPDF
Camelot

Al in all you can tune a lot your code and you can manual add OCR.

option all in all solution for the future:

docling - (opensource on github)

it give some ready to use examples, which are already pretty good, ~10-20 code-lines.
https://github.com/docling-project/docling/tree/main/docs/examples
also for OCR it download automatic some models. the only thing i haven't found yet (maybe it doesn't exist) is to read out the font-type, which works very well with fitz, for example.

large option to play with many types of (UI-Based)

Parsemy PDF

https://github.com/genieincodebottle/parsemypdf

...

only Indexing option

One hint for fast search on 10000s of PDF (its only indexing not embedding) you can use it as a simple way to find your top 5-10 articles or books, you can then make these available to an LLM.
Jabref - https://github.com/JabRef/jabref/tree/v6.0-alpha?tab=readme-ov-file
https://builds.jabref.org/main/
or
docfetcher - https://docfetcher.sourceforge.io/en/index.html (yes old but very useful)

...
" on discord sevenof9 "

...

(ALL licenses and terms of use go to original author)

...

avemio/German-RAG-BGE-M3-MERGED-x-SNOWFLAKE-ARCTIC-HESSIAN-AI (German, English)
maidalun1020/bce-embedding-base_v1 (English and Chinese)
maidalun1020/bce-reranker-base_v1 (English, Chinese, Japanese and Korean)
BAAI/bge-reranker-v2-m3 (English and Chinese)
BAAI/bge-reranker-v2-gemma (English and Chinese)
BAAI/bge-m3 (English and Chinese)
avsolatorio/GIST-large-Embedding-v0 (English)
ibm-granite/granite-embedding-278m-multilingual (English, German, Spanish, French, Japanese, Portuguese, Arabic, Czech, Italian, Korean, Dutch, and Chinese)
ibm-granite/granite-embedding-125m-english
Labib11/MUG-B-1.6 (?)
mixedbread-ai/mxbai-embed-large-v1 (multi)
nomic-ai/nomic-embed-text-v1.5 (English, multi)
Snowflake/snowflake-arctic-embed-l-v2.0 (English, multi)
intfloat/multilingual-e5-large-instruct (100 languages)
T-Systems-onsite/german-roberta-sentence-transformer-v2
mixedbread-ai/mxbai-embed-2d-large-v1
jinaai/jina-embeddings-v2-base-en