Choosing Dify's index method before your first document is loaded
For most knowledge bases that answer questions in natural language, choose High Quality indexing, and reserve Economical for collections where exact keyword matching is enough. Make this decision before the first document is loaded, because the choice is effectively one-way: High Quality cannot revert to Economical, so moving an existing knowledge base to the other method means re-indexing or building a new knowledge base. Confirm the exact switching behavior in the Dify documentation for your version before you plan your test data. The index method is set per knowledge base, so one instance can hold both kinds if your corpora differ.
The index method controls how Dify finds the passages it passes to the model. High Quality builds embeddings with your chosen embedding model and stores them in a vector store, so a question about a "device refresh" policy can match a chunk that says "laptop replacement." Economical builds a keyword index, so a query matches the terms it contains. Keyword retrieval is more precise for product codes, contract numbers, error strings and clause identifiers, where a semantic match can pull in a near miss. The cost difference sits in three places: embedding model calls at indexing and query time (billed by your model provider or run on infrastructure you operate), vector store capacity for the default Weaviate or an alternative, and the engineering time to size and back up that store. Economical avoids the first two.
Before loading the full corpus, build a small knowledge base from representative documents, collect a set of questions from support queues or analysts, and run retrieval testing with each index method. Compare which passages come back for each question. If most questions name exact identifiers, Economical may be enough and you avoid the embedding spend. If users paraphrase or write differently from the source text, High Quality is the safer default, and you should budget for its model and storage costs. Ask your model provider or internal platform team to confirm where the embedding model runs, how it is billed, and whether document text leaves your boundary, because those answers decide whether the High Quality path fits your data handling rules.
Index method options and when each fits
This table compares High Quality (embedding-based) and Economical (keyword-based) indexing across retrieval behavior, cost drivers and data handling. Read each row as a question to answer for your own knowledge base before you pick an index method, since the choice is hard to reverse. The main takeaway is that Economical indexing removes the embedding dependency and its external calls, but it gives up semantic matching on paraphrased questions.
| Factor | High Quality (embedding index) | Economical (keyword index) |
|---|---|---|
| Retrieval style | Matches meaning using vector similarity, so differently worded questions can find the same segment | Matches terms and keywords, so retrieval depends on the wording of the question overlapping the wording of the source |
| Embedding model dependency | Requires a configured embedding model at indexing and at query time | Does not require an embedding model for indexing or retrieval |
| Indexing cost drivers | Embedding calls scale with the number of chunks and re-indexing events, and the model choice sets the unit cost | Mainly local compute and storage for the keyword index, so cost grows slowly with document volume |
| Paraphrased questions | Usually handles paraphrases and synonyms well, though quality depends on the embedding model and chunking | Often misses paraphrases, synonyms and domain abbreviations unless the source text uses the same terms |
| Data handling | Chunk text is sent to the embedding provider you configure, which may be a cloud service or a self-hosted model; confirm the endpoint for each | Indexing does not call an external embedding service, so content stays within the Dify deployment and its storage |
| Reversibility | Switching back to Economical is not supported, so plan the index method before bulk ingestion | Switching to High Quality later requires indexing the content with an embedding model, which adds cost and time |
| When keyword indexing is enough (test, do not assume) | Not applicable | Consider it when test questions use the same terms as the documents, answers sit in short factual passages, and retrieval tests in your environment return the right segments |
Why a High Quality knowledge base cannot switch back to Economical
In Dify, moving a knowledge base from High Quality to Economical is a one-way decision, and the cards below describe what that means in practice. Each one is a consequence to plan for before the first document is indexed, not after retrieval results disappoint. Confirm the exact switch behavior in the Dify version you run before you design around it.
Existing vectors stay in place
Changing the index setting does not discard the embeddings already created for a knowledge base. Those vectors remain in the vector store and the knowledge base keeps its High Quality configuration, so the setting does not work as a rollback control. Check in a test workspace what the console allows you to change after documents are indexed, and record the result for your runbook.
Re-index means a new knowledge base
The practical path to Economical is to create a new knowledge base with the keyword index, upload or import the source documents again, and point applications at the new base. Re-indexing is a full ingestion pass, so plan time for document preprocessing, chunking and the keyword index build. Ask whether your Dify version can migrate an existing base in place before you assume a rebuild.
Embedding cost is duplicated
While both knowledge bases exist, the documents are embedded twice if you keep the High Quality base running during cutover. Embedding calls go to your model provider or self-hosted endpoint and are billed or consumed on that side, not by Dify. Estimate the duplicated volume from your document inventory and the provider's pricing before committing to a parallel run.
App references need repointing
Each workflow, chatflow or agent that uses a knowledge base holds a reference to that specific base. A new knowledge base does not inherit those references, so every app must be updated and tested. Inventory the apps that use the old base in the app management view, and assign an owner to each before cutover.
API integrations point at the old base
External systems that ingest documents or query retrieval through the Knowledge API address the knowledge base by its ID. Scripts, sync jobs and dataset-scoped API keys tied to the old base will keep writing to or reading from the wrong place unless you change them. Document each integration, rotate keys where needed, and confirm that the old base is quiet before you retire it.
Retrieval behavior changes on cutover
Keyword search returns different chunks than vector similarity, so answers can shift even when the source documents are identical. Treat the switch as a change to retrieval, not only to storage, and run a set of real questions against both bases before users see the new one. Keep the High Quality base available until the comparison is signed off.
How to set up and compare index methods in Dify
This sequence builds a test knowledge base, indexes the same documents under each method, and checks retrieval results with real questions before any app depends on the index. The output is a documented decision on which index method fits the content and the budget.
Confirm the Dify version and vector store
Before creating anything, confirm which Dify version runs in your environment and which vector store the deployment uses. Dify's environment reference says the vector store defaults to Weaviate, with other options such as Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch. Check the active setting in your
.envfile and confirm the vector store container is running and reachable from the api and worker services. Done when the vector store type is written down and a health check from the Dify console or logs shows no connection errors.Create a test knowledge base
Create a dedicated test knowledge base in a non-production workspace so that experiments do not mix with live content. Name it clearly, for example as a test copy of the content you plan to use, and do not reuse a production knowledge base. The workspace owner or a designated builder with knowledge base creation rights performs this step. Done when the knowledge base appears in the workspace list and its settings page opens without error.
Select the index method and embedding model
In the knowledge base settings, choose High Quality for embedding-based indexing or Economical for keyword-based indexing. If you choose High Quality, select an embedding model from the providers configured in your workspace, and record which model you chose. Economical indexing does not use an embedding model, so no embedding provider is called for it. Note that the Dify docs describe High Quality as a one-way choice for a knowledge base, so create a separate test knowledge base for the other method rather than switching. Done when the settings show the chosen index mode and, for High Quality, the embedding model name.
Upload a representative document set
Upload a sample that reflects the real corpus: the document formats, lengths, tables, and terminology your users will query. Include a few documents that are known to be hard, such as long policies with similar wording across versions. Keep the same document set for every index method you compare so that results are comparable. Confirm file types and sizes against the built-in extraction and upload limits described in the Dify docs before uploading. Done when every document shows an indexing status of completed, and any failed documents are listed with their reasons.
Run retrieval tests with real questions
Prepare a set of questions drawn from real users, support tickets or subject-matter experts, along with the passages a correct answer should cite. Run each question through the retrieval testing feature for the High Quality knowledge base and for the Economical one, and record the returned segments and their order. Keep the retrieval settings identical across both runs so that only the index method changes. Done when every question has a recorded result for each index method in a shared table.
Score the results and record the decision
Review each question against the expected passages. Mark whether the correct segment appeared, at what position, and whether paraphrased questions or synonyms were handled. Pay particular attention to questions that use different wording from the source, since keyword matching often misses them, and to exact identifiers, codes or names, where keyword matching often performs well. Record the findings alongside the embedding model and index mode so the result can be repeated later. Done when a reviewer other than the builder has checked the scoring and the team has written down which index method meets the requirement.
Check results before connecting an app
Before any app references the knowledge base, confirm the chosen index mode in the knowledge base settings, verify the vector store connection once more, and confirm the knowledge base is the one the app will use. Remember that the index method cannot be reverted from High Quality to Economical, so if the test favored a different method, create a new knowledge base and re-upload the documents rather than attempting a change. Done when the app references the intended knowledge base, a sample query returns the expected segments, and the decision record is stored with the deployment documentation.
What drives the cost of High Quality indexing
High Quality indexing adds cost in three places: model calls when documents are indexed, the vector store that holds the results, and the infrastructure that runs both. Some of these costs are paid once per document set, while others recur as content changes and queries run. The cards below separate the two so you can ask a partner or your own team for the right numbers.
Embedding model usage at indexing
High Quality indexing sends every chunk of every document to an embedding model, so the bill scales with total text volume, chunk size and overlap. Chunks created by overlap are embedded again, which adds cost without adding new content. Ask whether the embedding model is hosted by a cloud provider (billed per token) or runs on your own inference server (billed as compute and staff time). Both costs land at indexing, not at query time.
Re-indexing after configuration changes
Changing the embedding model, chunk settings or preprocessing rules generally means the affected documents must be embedded again. Because High Quality cannot revert to Economical in place, a change of direction also means building a new index. Plan for a repeat of the full indexing cost each time the embedding model changes, and ask your partner how many re-index cycles the quote assumes.
Vector store resources and storage
Dify defaults to Weaviate for its vector store, and other options include Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch. Each stores vectors that grow with the number of chunks and the dimensions of the embedding model, so memory, disk and backup size rise with the corpus. Confirm which store you will run, who operates it, and whether backups of the vector data are priced separately from the Dify database.
Infrastructure to run the vector service
Vector search adds a stateful service that needs CPU, memory, persistent volumes and monitoring on top of the base Dify stack. The Docker Compose deployment already starts Weaviate with the api, worker, PostgreSQL and Redis, and it requires at least 2 CPU cores and 4 GB of RAM as a baseline. Larger corpora or more concurrent retrievals call for more capacity. Ask for a sizing assumption tied to your document count, not a flat server price.
Recurring query and storage cost
After indexing, each retrieval call uses the vector store, and each answer may call an embedding model for the user's question and a reranker if one is configured. These costs recur with usage and keep running as long as the knowledge base is live. Separate them from the one-time indexing charge in any quote, and ask for an estimate of monthly query volume and stored data size.
What to request in a quote
Ask for a line-item breakdown: embedding calls at indexing, expected re-index cycles, vector store installation and sizing, backup and restore of vector data, and ongoing operations. Request the document count, average size, chunk settings and target model assumed for each line. A quote that cannot state these inputs cannot be compared with your own team's estimate.
Questions teams ask before choosing an index method
Is the Economical keyword index enough for our Dify knowledge base?
Keyword indexing is enough when users ask with the same terms that appear in your documents and the content is mostly short, precise reference material such as product codes, policy numbers or internal names. It is a weaker fit when users paraphrase, ask conceptual questions, mix languages or expect the system to match meaning rather than words. Policy can also decide it: if you cannot send document text to an embedding provider, a keyword index may be the only option that keeps indexing inside your environment. Test this on your own content. Build a set of real questions with known source passages and check whether the right passage comes back under each index method before you commit.
Can a Dify knowledge base switch from High Quality back to Economical?
Plan on treating the choice as one-way. High Quality indexing builds embeddings that the Economical keyword index does not use, so reverting is not a simple setting change. If you need to move back, the practical route is usually a new knowledge base with the Economical method and the documents loaded again. Moving in the other direction also requires indexing content with the embedding path, so the work is not free either way. Confirm the exact switching behavior in the Dify documentation for the version you run, and check it again before each upgrade, because index behavior can change between releases.
What drives the cost of High Quality indexing in Dify?
The cost has several components, and each is paid to someone different. The embedding model is the most visible: if it is a hosted provider, you pay per use, and if it runs on your own inference server, you pay for the hardware and its operation. The vector store, which defaults to Weaviate and can be swapped for other supported options, needs storage and memory that grow with the number of chunks. Worker compute runs the indexing jobs. Some costs are one-time, such as the first full indexing run. Others recur, including indexing new documents, re-indexing after a chunking change and the infrastructure that stays on. Ask any quote to state who pays for each component and what volume it assumes.
How long does re-indexing a Dify knowledge base take?
The duration depends on the number and size of documents, the chunking settings that set how many chunks are produced, the throughput of the embedding model or provider, provider rate limits, the number of worker processes and the capacity of the vector store. Keyword-only indexing does not call an embedding model, so it is usually lighter, but confirm the cost profile for your version. The most reliable way to estimate is to index a representative sample of your documents with the same settings, measure how long it takes, and scale that measurement to the full set. Ask any partner to base its schedule on that measurement and to name the assumptions it depends on.
Can our own team set up High Quality indexing without a partner?
Yes, a capable internal team can do it. The Community edition of the self-hosted platform is free and limited to a single workspace, so the software cost is not the barrier. The work is operational: configuring an embedding model with credentials you control, choosing and sizing a vector store, setting chunking and retrieval options, building a test set and running re-indexes on a schedule. Someone must own the model endpoints, the infrastructure and the evaluation. A partner adds value when you want a fixed scope, written deliverables and an independent review of the index choice, or when the team lacks time for the testing. Enterprise features such as SSO and multiple workspaces are priced separately and are not required for this decision.
What does the work need from our team to decide the index method?
Expect to provide four things. First, a set of real questions from users or support tickets, with the document or passage that should answer each one, sanitized where needed. Second, access to representative documents in every format you use, so the test covers scanned, tabular and text-heavy files. Third, access to the model provider accounts or approved model endpoints, and to the Docker host, PostgreSQL and vector store for the environment where Dify will run. Fourth, a named owner who can sign off on the trade-off between cost, accuracy and data handling. Ask whether the partner also needs a sample of documents that are classified as sensitive, so that the data path can be reviewed before any content is sent to an embedding service.
Does the index method change where our document text goes?
Yes. With High Quality indexing, document chunks are turned into embeddings by an embedding model. If that model is a hosted provider, chunk text leaves your environment and falls under that provider's terms and your data processing agreement. If the embedding model runs on infrastructure you control, the text stays inside your boundary. Economical indexing keeps keyword processing within Dify's own storage. For regulated data, record which model endpoints touch document text, where they run, how credentials are stored and who approved each one. Those records serve as evidence for your internal reviewers and for any external assessor, although they do not replace an assessment by an independent auditor.
How should we validate the index choice before going live?
Run the same test set against both index methods with identical chunking settings, so the only variable is the index. For each question, record whether the expected passage appears in the results and at what rank. When a question fails, decide whether the cause is the chunking, the index method or the content itself, because the fix differs for each. Record the indexing time and resource use for each method on the sample, since these figures drive the cost decision. Repeat the test after major document changes and before every Dify upgrade. The companion guide on testing and tuning retrieval quality covers the signals that point to a chunking problem rather than a model problem.
When the keyword index is enough and when it is not
Economical indexing is enough when users search with the same words the documents use and the answer sits in a clearly bounded passage. That describes many structured or terminology-heavy sets: product catalogs keyed by part number, error code tables, policy documents with defined terms, and internal forms with fixed field names. Exact-term matching finds an identifier such as ERR-4021 or a clause number reliably, and a keyword index adds no embedding calls at indexing or query time. Before you choose it, list the questions the team expects most often and check whether the answer passages contain the words those questions use. If that holds for most of them, a keyword index is a defensible starting point for that knowledge base.
Move toward semantic retrieval when users paraphrase. The clearest sign is a retrieval test where a question phrased the way a customer or employee would ask it returns the wrong chunk, while the same question written with the document's own terms returns the right one. Other signals include questions written in a different language from the source documents, several teams naming one thing differently, and long natural-language questions where the key term never appears in the answer passage. Build the test set from questions users submit, including their paraphrases, and score each index against it. Record which questions fail and whether the failures cluster by topic, since clusters show where vocabulary mismatch is driving the misses.
Treat a poor result as a chunking question before you treat it as an index question. Oversized chunks dilute keyword matches, boundaries that separate a heading from its table send the answer to the wrong place, and boilerplate can outscore the passage a user needs. These faults affect both index types, so moving to High Quality will not repair them on its own. Check chunk mode, maximum length and text cleaning on the failing documents first, then rerun the same questions. Because the index type cannot revert once High Quality is set, build a separate test knowledge base from the same files, compare both indexes there, and confirm how the switch behaves in your Dify version before you change the production knowledge base.
