You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rerank --> Cut["Top K cut\nrag.retrieval.inline.max_chunks"]
64
+
65
+
Cut --> Context["Final Inline RAG Context"]
66
+
```
67
+
68
+
Each BYOK store is queried in parallel, and the merged BYOK results are capped at `rag.byok.max_chunks` total. OKP fetches up to `rag.okp.max_chunks`. Together these form the reranking pool. If the reranker is enabled, the full pool is reranked with a cross-encoder and BYOK score boosts are applied. The result is capped at `rag.retrieval.inline.max_chunks`.
69
+
43
70
The **Embedding Model** is used to convert queries and documents into vector representations for similarity matching.
44
71
45
72
> [!NOTE]
@@ -63,32 +90,28 @@ Use the [`rag-content`](https://github.com/lightspeed-core/rag-content) reposito
63
90
Download a local embedding model such as `sentence-transformers/all-mpnet-base-v2` by using the script in [`rag-content`](https://github.com/lightspeed-core/rag-content) or manually download and place in your desired path.
64
91
65
92
> [!NOTE]
66
-
> The embedding model can also be downloaded automatically at first start-up (which will be slower). In the `byok_rag` section of `lightspeed-stack.yaml`, specify a supported model name as `embedding_model` instead of a local path. The model will be downloaded to the `~/.cache/huggingface/hub` folder.
93
+
> The embedding model can also be downloaded automatically at first start-up (which will be slower). In the `rag.byok.stores` section of `lightspeed-stack.yaml`, specify a supported model name as `embedding_model` instead of a local path. The model will be downloaded to the `~/.cache/huggingface/hub` folder.
67
94
68
95
---
69
96
70
97
## Configure BYOK Knowledge Sources
71
98
72
-
> [!WARNING]
73
-
> **Deprecated in 0.7.0**: The top-level `byok_rag`, `rag`, `okp`, and `reranker` sections
74
-
> are deprecated. In 0.7.0, all RAG-related configuration is unified under a single `rag`
75
-
> section: stores move to `rag.byok.stores` (with `backend` instead of `rag_type`),
76
-
> retrieval strategies move to `rag.retrieval.inline`/`rag.retrieval.tool`, OKP moves to
77
-
> `rag.okp`, and the reranker moves to `rag.retrieval.inline.reranker`.
78
-
> See the [v0.7.0 Migration Guide](migrations/v0.7.0.md) for full details and examples.
79
99
80
-
BYOK knowledge sources are configured in the `byok_rag` section of `lightspeed-stack.yaml`. The required configuration is automatically generated at startup when using `make run`, `make run-stack`, `docker-compose`, or library mode — no manual enrichment is needed.
100
+
101
+
BYOK knowledge sources are configured in the `rag.byok.stores` section of `lightspeed-stack.yaml`. The required configuration is automatically generated at startup when using `make run`, `make run-stack`, `docker-compose`, or library mode — no manual enrichment is needed.
81
102
82
103
### FAISS example
83
104
84
105
```yaml
85
-
byok_rag:
86
-
- rag_id: custom-index
87
-
rag_type: inline::faiss
88
-
embedding_model: sentence-transformers/all-mpnet-base-v2 # or path to local model
89
-
embedding_dimension: 768
90
-
vector_db_id: vs_8c94967b-81cc-4028-a294-9cfac6fd9ae2 # Generated by rag-content during index creation
91
-
db_path: <path-to-vector-index> # e.g. /home/USER/vector_db/faiss_store.db
106
+
rag:
107
+
byok:
108
+
stores:
109
+
- rag_id: custom-index
110
+
backend: faiss
111
+
embedding_model: sentence-transformers/all-mpnet-base-v2 # or path to local model
112
+
embedding_dimension: 768
113
+
vector_db_id: vs_8c94967b-81cc-4028-a294-9cfac6fd9ae2 # Generated by rag-content during index creation
114
+
db_path: <path-to-vector-index> # e.g. /home/USER/vector_db/faiss_store.db
92
115
```
93
116
94
117
Where:
@@ -117,17 +140,19 @@ Each pgvector-backed table follows this schema:
117
140
> The `vector_store_id` (e.g. `rhdocs`) is used to point to the table named `vector_store_rhdocs` in the specified database, which stores the vector embeddings.
@@ -302,21 +327,23 @@ The OKP (Offline Knowledge Portal) Solr Vector IO is a read-only vector search p
302
327
303
328
```yaml
304
329
rag:
305
-
inline:
306
-
- okp # inject OKP context before the LLM request
307
-
tool:
308
-
- okp # expose OKP as the file_search tool
309
-
310
-
okp:
311
-
rhokp_url: ${env.RH_SERVER_OKP} # OKP base URL (env var or literal URL)
312
-
offline: true # true = use parent_id for source URLs (offline mode)
313
-
# false = use reference_url (online mode)
330
+
retrieval:
331
+
inline:
332
+
sources:
333
+
- okp # inject OKP context before the LLM request
334
+
tool:
335
+
sources:
336
+
- okp # expose OKP as the file_search tool
337
+
okp:
338
+
rhokp_url: ${env.RH_SERVER_OKP} # OKP base URL (env var or literal URL)
339
+
offline: true # true = use parent_id for source URLs (offline mode)
340
+
# false = use reference_url (online mode)
314
341
```
315
342
316
-
Set `rhokp_url` to the base URL of your OKP server. Use `${env.RH_SERVER_OKP}` to read the URL from the environment; when omitted or empty, a default from the application constants is used.
343
+
Set `rhokp_url` to the base URL of your OKP server under `rag.okp`. Use `${env.RH_SERVER_OKP}` to read the URL from the environment; when omitted or empty, a default from the application constants is used.
317
344
318
345
> [!NOTE]
319
-
> When `okp` is listed in `rag.inline` or `rag.tool`, Lightspeed Stack automatically enriches
346
+
> When `okp` is listed in `rag.retrieval.inline.sources` or `rag.retrieval.tool.sources`, Lightspeed Stack automatically enriches
320
347
> the underlying configuration at startup with the required `vector_io` provider and `registered_resources`
321
348
> entries for the OKP vector store. No manual registration is needed.
322
349
@@ -342,14 +369,15 @@ curl -sX POST http://localhost:8080/v1/query \
342
369
343
370
**Query Filtering:**
344
371
345
-
To further filter the OKP context, set the `chunk_filter_query` field in the `okp` section of
372
+
To further filter the OKP context, set the `chunk_filter_query` field in the `rag.okp` section of
346
373
`lightspeed-stack.yaml`. Filters follow the OKP key:value format and are applied as a static
347
374
`fq` parameter on every OKP search request.
348
375
349
376
```yaml
350
-
okp:
351
-
rhokp_url: ${env.RH_SERVER_OKP}
352
-
chunk_filter_query: "product:*openshift*"
377
+
rag:
378
+
okp:
379
+
rhokp_url: ${env.RH_SERVER_OKP}
380
+
chunk_filter_query: "product:*openshift*"
353
381
```
354
382
355
383
Per-request filtering is also available on all inference endpoints via request field **`solr`**: `mode` (`semantic`, `hybrid`, or `lexical`) and `filters` (key:value format). Legacy payloads that omit `mode`/`filters` and send filter key:value pairs at the top level still work with `mode` set to `hybrid`.
@@ -368,28 +396,24 @@ Example:
368
396
369
397
**Prerequisites:**
370
398
371
-
- The OKP server must be running and accessible at the URL given in `okp.rhokp_url` (or `${env.RH_SERVER_OKP}`).
399
+
- The OKP server must be running and accessible at the URL given in `rag.okp.rhokp_url` (or `${env.RH_SERVER_OKP}`).
372
400
For instructions on how to pull and run the OKP image, visit: https://github.com/lightspeed-core/lightspeed-providers/lightspeed_stack_providers/providers/remote/solr_vector_io/solr_vector_io/README.md
373
401
374
402
375
403
**Chunk volume:**
376
404
377
-
> [!WARNING]
378
-
> **Deprecated in 0.7.0**: The chunk limit constants below are replaced by configurable
379
-
> fields in `lightspeed-stack.yaml` (`rag.byok.max_chunks`, `rag.okp.max_chunks`,
> See the [v0.7.0 Migration Guide](migrations/v0.7.0.md) for details.
382
405
383
406
OKP and BYOK scores are not directly comparable (different scoring systems), so
384
-
`score_multiplier` (a BYOK-only concept) does not apply to OKP results. To control
385
-
the number of retrieved chunks, set the constants in `src/constants.py`:
407
+
`score_multiplier` (a BYOK-only concept) does not apply to OKP results. However, when
408
+
the reranker is enabled, it normalizes scores across sources using a cross-encoder model.
409
+
To control the number of retrieved chunks, configure `max_chunks` in `lightspeed-stack.yaml`:
386
410
387
-
|Constant | Value| Description |
388
-
|----------|-------|-------------|
389
-
|`INLINE_RAG_MAX_CHUNKS`| 10 | Hard upper bound on the final merged inline RAG chunks (BYOK + OKP) delivered to the LLM |
390
-
|`OKP_RAG_MAX_CHUNKS`| 5 | Fetch hint for OKP (Inline RAG); controls how many chunks enter the reranking pool |
391
-
|`BYOK_RAG_MAX_CHUNKS`| 10 | Fetch hint for BYOK stores (Inline RAG); controls how many chunks enter the reranking pool |
392
-
|`TOOL_RAG_MAX_CHUNKS`| 10 | Max chunks retrieved via Tool RAG (`file_search`); independent from `INLINE_RAG_MAX_CHUNKS`|
411
+
|Config path | Default| Description |
412
+
|-------------|---------|-------------|
413
+
|`rag.retrieval.inline.max_chunks`| 10 | Hard upper bound on the final merged inline RAG chunks (BYOK + OKP) delivered to the LLM |
414
+
|`rag.okp.max_chunks`| 5 | Fetch limit for OKP (Inline RAG); controls how many chunks enter the reranking pool |
415
+
|`rag.byok.max_chunks`| 10 | Fetch limit for BYOK stores (Inline RAG); controls how many chunks enter the reranking pool |
416
+
|`rag.retrieval.tool.max_chunks`| 10 | Max chunks retrieved via Tool RAG (`file_search`); independent from inline max_chunks|
393
417
394
418
**Limitations:**
395
419
@@ -399,9 +423,7 @@ the number of retrieved chunks, set the constants in `src/constants.py`:
399
423
400
424
# Complete Configuration Reference
401
425
402
-
To enable RAG functionality, configure the `byok_rag` and `rag` sections in
403
-
your `lightspeed-stack.yaml`. Add `vector_store` when you also need
404
-
runtime `POST /v1/vector-stores` capacity.
426
+
To enable RAG functionality, configure the `rag` section (including `rag.byok.stores` and `rag.retrieval`) in your `lightspeed-stack.yaml`. Add `vector_store` when you also need runtime `POST /v1/vector-stores` capacity.
405
427
406
428
Below is an example of a working `lightspeed-stack.yaml` configuration with:
BYOK providers and registered resources are generated at startup from
450
-
`byok_rag`. Dynamic providers and create defaults are generated from
451
-
`vector_store`during unified synthesis. Embedding models for
452
-
those providers are registered automatically when needed. Inference models
453
-
and providers must still be configured separately (for example in your
454
-
baseline / profile `run.yaml`).
474
+
BYOK providers and registered resources are generated at startup from `rag.byok.stores`. Dynamic providers and create defaults are generated from `vector_store` during unified synthesis. Embedding models for those providers are registered automatically when needed. Inference models and providers must still be configured separately (for example in your baseline / profile `run.yaml`).
0 commit comments