Added information about guardrails#6
Conversation
9a5d7bb to
0ee7642
Compare
|
Added a note related to this here os2ai/helm-deployments#28 (comment) I'll review this with my feedback in mind. |
|
@SigneA-hm this should be reviewed and merged |
|
I'll withdraw from this review and let's @hypesystem take the wheel. |
hypesystem
left a comment
There was a problem hiding this comment.
Nice, I like the documentation overall, it gives me a good idea of the general approach.
I've added some notes, mostly where I think some more abstract/broader context is warranted, so readers are more likely to understand not just what we are doing, but why 😄
| - `_repair_tool_call_pairings` — strip orphan `role: tool` messages and orphan `tool_calls` entries that the trimmer | ||
| may have created. | ||
| - (Optional, opt-in via `pop_trailing_tool_messages`) pop trailing `role: tool` messages and re-run the repair, then | ||
| append `"Please continue"` if the new terminus is an assistant message. |
There was a problem hiding this comment.
"Please continue" feels like it could skew the output, especially if the language in the context window otherwise isn't English?
|
|
||
| The message trimming guardrail can be configured in the litellm | ||
| values [file](https://github.com/os2ai/helm-deployments/blob/develop/applications/litellm/litellm-values.yaml#L108) | ||
| configuration file in the helm chart. |
There was a problem hiding this comment.
A note on why we need message trimming would make sense after this paragraph, just very briefly. E.g. what happens if oversized message histories are not trimmed, and how does the guardrail avoid it? In a sentence of two.
There was a problem hiding this comment.
Added comment about this to the doc
| ### Why the trailing-tool pop is opt-in | ||
|
|
||
| The "normal" agent-loop shape ends on a `role: tool` message: | ||
|
|
||
| ```mermaid | ||
| flowchart LR | ||
| U[User] --> A["Assistant{tool_calls}"] | ||
| A --> T["Tool{result}"] | ||
| T --> C([model is asked to continue here]) | ||
| ``` | ||
|
|
||
| Most providers (OpenAI, Anthropic, Google, Mistral via the official APIs) __accept__ this shape — that's how tool | ||
| calling works. Popping the tool message and substituting `"Please continue"` deprives the model of the result it was | ||
| supposed to reason from, so the default is __off__. |
There was a problem hiding this comment.
I don't understand this section. Specifically Popping the tool message and substituting "Please continue" deprives the model of the result it was supposed to reason from, so the default is __off__. doesn't really tell me what happens in the cases where the setting is enabled vs disabled, and what exactly the default behavior is.
What is the effect of depriving the model of the result it was supposed to reason from? (Am I understanding it correctly that this refers to "the result of the tool call", and if so, could we call it that?)
There was a problem hiding this comment.
Tried to explain it better
|
|
||
| ## How Message Trimming works | ||
|
|
||
| `async_pre_call_hook` runs on every chat completion request. The flow: |
There was a problem hiding this comment.
Before the step-by-step flow, I think a sentence stating what the pros and cons of our approach is would make sense.
E.g. "Sending a too large message to the model can be fatal for the entire conversation, so we take a conservative approach in estimating a safe completion budget for the message" and then explain what a safe completion budget is, why we calculate it as is? I think that would give a lot of good context for evaluating the approach.
There was a problem hiding this comment.
Intro section added
hypesystem
left a comment
There was a problem hiding this comment.
As discussed in today's meeting, here's a suggested text explaining the context between Open WebUI and LiteLLM and how guardrails are attached.
0ee7642 to
d10dc26
Compare
d10dc26 to
ea8c468
Compare
0df92e6 to
ad9bb8d
Compare
|
Tried to answer the questions as good as I can. |
mermaiddiagrams in this docs site