[
https://issues.apache.org/jira/browse/HDDS-15911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arafat Khan updated HDDS-15911:
-------------------------------
Description:
*Problem* The Recon chatbot treats every question independently. Follow-ups
that rely on earlier context "show me the keys there", "what about bucket2",
"show me more" fail because the assistant has no memory of the previous turn.
*Proposed change* Add lightweight, client-side conversation memory:
* The client resends the recent turns of the conversation with each request
(new optional {{history}} field on the chat request).
* The Recon server stays completely stateless - no session store. It just
trims the history to a safe budget and injects it as _context_ into the
tool-selection step so the model can resolve references in the current question.
* History is used only to understand the current question; the assistant
always answers the CURRENT question, never the old ones.
*Config (server-enforced) — only two knobs*
* {{ozone.recon.chatbot.history.enabled}} = {{true}} - master on/off switch
* {{ozone.recon.chatbot.history.max.chars}} = {{8000 -}} total history budget
(~2k tokens); the single size dial. Raise it for large-context models, lower it
for small ones.
Everything else is a fixed internal behaviour (not config): keep at most the
last ~4 Q/A pairs, truncate long past answers, and keep past questions
near-intact (they carry the references).
*Safety* History is treated as untrusted input. It's a hint only - the existing
tool allowlist and listKeys safe-scope checks remain the real guardrails, so
behavior stays safe even if the history is malformed or malicious.
*Detailed Design Doc* -
https://docs.google.com/document/d/18HjRzQCUHriKAiNiLkU6dgYGjIduOZSkeOSqK1362sQ/edit?tab=t.0#heading=h.f2l5eefpzm5p
was:
*Problem* The Recon chatbot treats every question independently. Follow-ups
that rely on earlier context "show me the keys there", "what about bucket2",
"show me more" fail because the assistant has no memory of the previous turn.
*Proposed change* Add lightweight, client-side conversation memory:
* The client resends the recent turns of the conversation with each request
(new optional {{history}} field on the chat request).
* The Recon server stays completely stateless - no session store. It just
trims the history to a safe budget and injects it as _context_ into the
tool-selection step so the model can resolve references in the current question.
* History is used only to understand the current question; the assistant
always answers the CURRENT question, never the old ones.
*Config (server-enforced) — only two knobs*
* {{ozone.recon.chatbot.history.enabled}} = {{true}} - master on/off switch
* {{ozone.recon.chatbot.history.max.chars}} = {{8000 -}} total history budget
(~2k tokens); the single size dial. Raise it for large-context models, lower it
for small ones.
Everything else is a fixed internal behaviour (not config): keep at most the
last ~4 Q/A pairs, truncate long past answers, and keep past questions
near-intact (they carry the references).
*Safety* History is treated as untrusted input. It's a hint only - the existing
tool allowlist and listKeys safe-scope checks remain the real guardrails, so
behavior stays safe even if the history is malformed or malicious.
> Recon AI Assistant: add conversation memory for follow-up questions.
> ---------------------------------------------------------------------
>
> Key: HDDS-15911
> URL: https://issues.apache.org/jira/browse/HDDS-15911
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: Ozone Recon
> Reporter: Arafat Khan
> Assignee: Arafat Khan
> Priority: Major
> Labels: pull-request-available
>
> *Problem* The Recon chatbot treats every question independently. Follow-ups
> that rely on earlier context "show me the keys there", "what about bucket2",
> "show me more" fail because the assistant has no memory of the previous turn.
> *Proposed change* Add lightweight, client-side conversation memory:
> * The client resends the recent turns of the conversation with each request
> (new optional {{history}} field on the chat request).
> * The Recon server stays completely stateless - no session store. It just
> trims the history to a safe budget and injects it as _context_ into the
> tool-selection step so the model can resolve references in the current
> question.
> * History is used only to understand the current question; the assistant
> always answers the CURRENT question, never the old ones.
> *Config (server-enforced) — only two knobs*
> * {{ozone.recon.chatbot.history.enabled}} = {{true}} - master on/off switch
> * {{ozone.recon.chatbot.history.max.chars}} = {{8000 -}} total history
> budget (~2k tokens); the single size dial. Raise it for large-context models,
> lower it for small ones.
> Everything else is a fixed internal behaviour (not config): keep at most the
> last ~4 Q/A pairs, truncate long past answers, and keep past questions
> near-intact (they carry the references).
> *Safety* History is treated as untrusted input. It's a hint only - the
> existing tool allowlist and listKeys safe-scope checks remain the real
> guardrails, so behavior stays safe even if the history is malformed or
> malicious.
> *Detailed Design Doc* -
> https://docs.google.com/document/d/18HjRzQCUHriKAiNiLkU6dgYGjIduOZSkeOSqK1362sQ/edit?tab=t.0#heading=h.f2l5eefpzm5p
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
