retrieval_type selects how queries are matched against indexed content. There are three modes. To see how each behaves, take one query a support team might run: “error 10015 on outbound call”.
Vector
Available The query is embedded into a vector and compared against indexed chunks by nearest-neighbor similarity. It matches on meaning, so wording can differ: “did we agree to a refund?” finds “we’ll credit the invoice”. For the example query, vector search understands the concept — call failures, error handling — and finds transcripts about failing outbound calls. Its blind spot is the literal string: the chunk containing exactly10015 may not rank first, because digits have weak semantic neighbors.
Best for natural-language questions where exact terms vary. This is the default mode.
Keyword
Coming soon Classic lexical search (BM25) — term-frequency ranking over the actual words, no embeddings. It matches on exact tokens, so it finds the chunk that literally contains10015. Its blind spot is paraphrase: a transcript that says “the call was rejected with a billing error” but never says “10015” is invisible to it.
Best for identifiers, error codes, SKUs, and names.
Hybrid
Coming soon Runs vector and keyword in parallel and fuses the two result sets into one ranking. For the example query it finds both the transcript with the literal10015 and the ones that only describe the failure — semantic recall plus exact-term precision in a single call, at the cost of slightly more work per request.
Best when queries are mixed or unpredictable.