The problem appears after a successful demo

A RAG pilot loads a few instructions and asks a model to find the relevant clause. Then the team connects contracts, rules from several departments and an archive of revisions. A question such as “show the current returns procedure for my branch” needs more than similar chunks: it needs constraints on branch, document type and revision status. If those fields were not planned before loading, the search design changes on an already operational corpus.

This does not mean that the database must necessarily be recreated. In Qdrant, a payload index added late still works for filtering. But its documentation notes an important distinction: the extra connections of filterable HNSW are built using payload indexes that already existed when the graph was constructed. To gain those optimizations for an existing graph, the graph must be rebuilt. Rebuilding takes resources and time; on a live service, it deserves a measured change plan and a rollback path.

The official Qdrant diagram on the cover shows separate parts inside a collection: payload, payload index and vector index are not one object. That distinction determines the order of work.

List the questions before listing the fields

Do not start with “index every column.” Take 20–30 real employee questions and record which constraints change an acceptable answer. For a product-return question, the organization, branch, effective revision, date and language may matter. The author's name or folder color probably does not belong in the query condition.

Turn those constraints into a stable chunk-level metadata schema. If a source file is split into several parts, every indexed chunk should inherit the key fields and source version. Otherwise one chunk may enter the correct result set while another loses its relationship to the document. Identifiers should be normalized: “Warehouse-1,” “warehouse 1” and an internal code must not accidentally become three different branches.

Divide fields into three groups:

  • mandatory access and search-scope constraints, such as organization, department or document group;
  • operational product filters, such as status, type, effective date and language;
  • descriptive metadata shown to the user, such as title, author and file path.

Fields in the first two groups are candidates for indexes when queries actually filter by them. Qdrant advises indexing fields used for filtering and warns that each payload index consumes memory, disk and build time. Independent Weaviate documentation reaches a similar practical conclusion: do not automatically index a property you never query. The exact settings and costs differ between systems, so their parameters cannot simply be copied across.

Order of work for a new collection

For Qdrant, a practical sequence is:

1. Define the chunk model: document ID, revision, source, fields used for filtering and an update method.
2. Create the collection with the selected vector dimensions and datatype.
3. Create payload indexes for known filters immediately. Field types should fit exact matching, range, date or text conditions.
4. Then load chunks and build the vector index.
5. Test queries with single and combined filters, as well as the quality of retrieved chunks.

Qdrant recommends creating payload indexes before loading because filterable HNSW adds connections based on values that are already indexed. But performance is not free: indexing every incidental field can enlarge the graph and prolong ingestion. In a project combining dense and sparse retrieval, some fields may only filter sparse search. Qdrant documents an option to avoid extra HNSW edges for such fields. That is a setting for a measured case, not a universal starting optimization.

What if the corpus is already loaded?

The first action is a test, not a rebuild during business hours. Capture the collection's current state; measure the latency of typical filtered queries and retrieval quality. Add the index in a separate test collection holding the same corpus. Compare p50, p95, ingestion time, index size and the share of queries where the necessary document appears among the first results. If the new design genuinely helps, schedule a rebuild or route traffic to a prepared collection after checking data versions.

Qdrant documents a way to force an HNSW rebuild after adding a payload index late. This is resource-intensive, not a button to press without checking spare capacity and a maintenance window. For a small business, the cost is not just hardware: while specialists reindex, they are not improving the underlying document process or answer quality. Defining the important fields early is often cheaper than a late, speculative optimization.

Do not confuse filtering with authorization. The server-side application must derive the search filter from a verified user role; a field in the vector database does not protect data on its own. After changing the schema, separately test attempts to request another user's chunk and the removal of outdated rights.

A minimal next step

Ask the process owner for ten questions the system should answer and five situations in which it must not answer. Mark the actual constraints, build a table with “field — type — data owner — query use — index required?” and load a limited corpus. Decide on a second or third index from query logs and measurements, not from the number of columns in the source system.

This pilot produces a useful result: retrieval architecture follows real work questions and access rules, while ingestion and rebuild costs become visible before the whole knowledge base goes live. That matters more than a fast answer on one demonstration PDF.

The diagram from Qdrant's official repository was cropped to a square without stretching; the source file is distributed under Apache 2.0.