Fix integrating indexing and retrieval pipelines to FileIndex (#155)
* Add docs for settings * Add mdx_truly_sane_lists to doc requirements
This commit is contained in:
committed by
GitHub
parent
2b3571e892
commit
cb01d27d19
8
docs/pages/app/settings/overview.md
Normal file
8
docs/pages/app/settings/overview.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# Overview
|
||||
|
||||
There are 3 kinds of settings in `ktem`, geared towards different stakeholders
|
||||
for different use cases:
|
||||
|
||||
- Developer settings. These settings are meant for very basic app customization, such as database URL, cloud config, logging config, which features to enable... You will be interested in the developer settings if you deploy `ktem` to your customers, or if you build extension for `ktem` for developers. These settings are declared inside `flowsettings.py`.
|
||||
- Admin settings. These settings show up in the Admin page, and are meant to allow admin-level user to customize low level features, such as which credentials to connect to data sources, which keys to use for LLM...
|
||||
- [User settings](/pages/app/settings/user-settings/). These settings are meant for run-time users to tweak ktem to their personal needs, such as which output languages the chatbot should generate, which reasoning type to use...
|
52
docs/pages/app/settings/user-settings.md
Normal file
52
docs/pages/app/settings/user-settings.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# User settings
|
||||
|
||||
`ktem` allows developers to extend the index and the reasoning pipeline. In
|
||||
many cases, these components can have settings that should be modified by
|
||||
users at run-time, (e.g. `topk`, `chunksize`...). These are the user settings.
|
||||
|
||||
`ktem` allows developers to declare such user settings in their code. Once
|
||||
declared, `ktem` will render them in a Settings page.
|
||||
|
||||
There are 2 places that `ktem` looks for declared user settings. You can
|
||||
refer to the respective pages.
|
||||
|
||||
- In the index.
|
||||
- In the reasoning pipeline.
|
||||
|
||||
## Syntax of a settings
|
||||
|
||||
A collection of settings is a dictionary of type `dict[str, dict]`, where the
|
||||
key is a setting id, and the value is the description of the setting.
|
||||
|
||||
```python
|
||||
settings = {
|
||||
"topk": {
|
||||
"name": "Top-k chunks",
|
||||
"value": 10,
|
||||
"component": "number",
|
||||
},
|
||||
"lang": {
|
||||
"name": "Languages",
|
||||
"value": "en",
|
||||
"component": "dropdown",
|
||||
"choices": [("en", "English"), ("cn", "Chinese")],
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Each setting description must have:
|
||||
|
||||
- name: the human-understandable name of the settings.
|
||||
- value: the default value of the settings.
|
||||
- component: the UI component to render such setting on the UI. Available:
|
||||
|
||||
- "text": single-value
|
||||
- "number": single-value
|
||||
- "checkbox": single-value
|
||||
- "dropdown": choices
|
||||
- "radio": choices
|
||||
- "checkboxgroup": choices
|
||||
|
||||
- choices: the list of choices, if the component type allows.
|
||||
|
||||
## Settings page structure
|
Reference in New Issue
Block a user