This is a collection of more than 25 types of embedding models and a really brief introduction to what you should know about embedding.If you don't keep a few things in mind, you won't be satisfied with the results.
at end of the file-list press
grafik
to see all files
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 and JAN(Menlo) is not build in right now but in development
I would always use f32 or f16 bit quality!
(sometimes the results are more truthful if the “chat with document only” option is used)
Incidentally, the Embedder model is only one part of a good RAG (Retrieval-Augmented Generation), but it should be tailored to your language and, if you want it to be completely accurate, also to the application, e.g. programming or medicine. ⇨ give me a ❤️, if you like ;)
My short impression:
nomic-embed-text-v2-moe (up to 512t context length)
mxbai-embed-large (small and fast model)
mug-b-1.6
qwen3-0.6b (slow but with 32k context but such large context is useless for usual queries/retrieval)
jinaai_v5-retrieval (qwen-based slow but with 40k context but such large context is useless for usual queries/retrieval)
snowflake-arctic-embed-l-v2.0 (up to 8192t context length)
bge-m3 (up to 8192t context length)
Working well, all other its up to you! Some models are very similar! (jina and qwen based you can add manual to LM-Studio, set model "gear wheel" below "overide domain type")
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.
Further tests have shown that the following models are suitable for complex tasks (German-text, but should be similar in English). Jina-DE, nomic was not that good. I'm not convinced by large models such as Qwen or JinaaiV3 and V4 doesnt work with LM studio; they are ten times slower and the result is not ten times better. Despite all this, you can recognize tables and some images.
GTE large
cross-en-de-es-roberta
ger-RAG-bge-M3-merg-snowf-artic-hessian-AI (very good for german, up to 8192t context length)
German-RAG-BGE-M3-TRIPLES-HESSIAN-AI (very good for german, up to 8192t context length)
bge-m3 (good for german, up to 8192t context length)
jina-embeddings-v3 (good for german, up to 8192t context length)
There are two embedder to find toxic content (toxic-prompt-roberta and minilmv2-toxic-jigsaw), dont know how good it works, and from ibm it give a whole LLM model (granite-guardian).
...
Short hints for using (Example for a large context with many expected hits):
Set your (Max Tokens)context-lenght 8000t main-LLM-model "LM-Studio with ALLM you must set also in LM-Stutio settings!", set your embedder-model (Max Embedding Chunk Length in character) 1500,set (Max Context Snippets, receiving) 10,
in ALLM set also (Text splitting & Chunking Preferences - Text Chunk Size) 1500 character parts and (Search Preference) "accuracy". And set in your workspace 10 snippets.
Hint in ALLM, set all in LM studio start both models and both are on top in ALLM.
-> Ok what that mean!
Your document will be embedd in x times 1500 character/chunks(snippets),
You can receive 10-snippets a 1500chars=15000chars (~4000token) from your document all in all -> ~2500words(2.5pages). now ~4000t left (from 8000t) for the answer ~2500words (2.5 pages). one question - one answer, with every setup i suggest only query once.
If you change your settings so that you receive more than 8000t in the response, you should use a good LLM model to obtain a detailed and meaningful response from such a large amount of content. It doesn't matter whether the model can process 100'000 tokens; that doesn't mean that this model can process 100'000 meaningfully.
You can play and set for your needs, eg 5-snippets a 5000chars, or 20-snippets a 500chars ... (every time you change the chunk-length the document must be embedd again). With these settings everything fits best for ONE answer.
english vs german differ 50% in calculate tokens/word
but ~5000 characters is one page of a book (no matter ger/en). But if you calculate with words ... words in german are longer, that means per word more token.
The example is english, for german you can add apox 50% more token/word (1000 words ~1800t)
1200t (~1000 words ~5000 character) ~0.1GB, this is aprox one page with small font
best to get in mind: 5000-6000 characters correspond to approximately one page and approximately 1200-1400 token.
8000t (~6000 words) ~1.5GB VRAM usage
16000t (~12000 words) ~3GB VRAM usage
32000t (~24000 words) ~6GB VRAM usage
Vector Size (Dimensions- you can not change)
The vector size, or dimensionality (embedding_length: xxx), is the number of numbers in each embedding vector.
Common embedding models produce vectors ranging from 384 dimensions (e.g., all-MiniLM-L6-v2) to 3072 dimensions (text-embedding-3-large).
Higher dimensions capture more semantic details but require more storage and computational resources for database indexing and search.
Some models allow you to shorten vectors (e.g., use only 256 out of 3072 dimensions) to save space while retaining high performance.
Vector count refers to the total number of vectors stored, which usually corresponds to the number of content chunks indexed +the overlap chracters space.
More vectors mean more granularity for search and retrieval but also increase database size and operational overhead sometimes 5times the size and also need more time for response.
Chunk Length
Chunk length is the size (usually measured in words, tokens, or characters) of the text split for embedding (ALLM chunk length/ chunk size -> in characters).
second VRAM calc for GGUF -> YOU need format "https://huggingface.co/provider/model/blob/main/model.gguf"
Example: "https://huggingface.co/unsloth/granite-3.3-8b-instruct-GGUF/blob/main/granite-3.3-8b-instruct-UD-Q8_K_XL.gguf" https://huggingface.co/spaces/NyxKrage/LLM-Model-VRAM-Calculator
...
How embedding and search works:
Embeddding is not a database, you can not ask how many times the word "xyz" appears. With embedding, you cannot ask for a summary of an entire book.
Example:
You have a txt/pdf file maybe 90000words(~300pages, ~1'000'000chars) 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 2000chars around this word “XYZ/ZYX” is cut out at this point. (In reality, it's all done with coded numbers per chunck and thats why you dont can search for single numbers or words, but dosnt matter - the principle)
This text snippet is then used for your answer.
If, for example, the word/meaning “XYZ” occurs 50 times in one txt, not all 50 are used for answer, only the number of snippets with the best ranking are used
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 20 snippet are fine)
If you expect multible search results in your docs try 15-snippets or more, if you expect only 2 than dont use more!
If you use chunk-length ~2000(chars) you receive more content, if you use ~500chars 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 CHAT, some options called "pin".
If a TXT file is embedded, you cannot create a summary! Only the snippets found are used for this purpose.
The same applies to word search or page search—in most cases, it does not work because it is not a word search but a search for similar expressions.
...
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.
Try to find a model that match your language!
Instruct models are better to answer questions from document!
For 8000 token and more context use models 8b better more.
If you are trying to tell stories from the answer, use other models...
...
Important -> The Systemprompt (some examples):
The system prompt is weighted with a certain amount of influence around your question, its not change your embedding/receiving result. 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."
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 to 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 ALLM its "c:\Users\XXX\AppData\Roaming\anythingllm-desktop\storage\documents", you can open with a text editor to check the quality.
In nearly all cases images and tables, page-numbers, chapters, formulas and sections/paragraph-format not well implement.
You can start by simply saving the PDF as a TXT file, and you will then see in the TXT file how the embedding-model would see the content.
An easy start is to use a python based pdf-parser (it give a lot) also OCR based for images.
option one only for simple txt/tables converting:
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)
