GIE-501(prompt): add query efficiency guidance to reduce excessive tool calls#46
GIE-501(prompt): add query efficiency guidance to reduce excessive tool calls#46slashpai wants to merge 1 commit intorhobs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: slashpai The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
slashpai
requested review from
iNecas and
saswatamcode
and removed request for
iNecas
- Add QUERY EFFICIENCY section to ServerPrompt with PromQL aggregation patterns (topk, sum by, rate) to prevent agents from querying one entity at a time - Mark Steps 2-3 (get_label_names, get_label_values) as optional when aggregated queries suffice - Add aggregation reminders to ExecuteInstantQueryPrompt and ExecuteRangeQueryPrompt Signed-off-by: Jayapriya Pai <janantha@redhat.com>
slashpai
force-pushed
the
query-efficiency-prompt
branch
from
3e3f5d0 to
fb9ac9a
Compare
|
@saswatamcode @iNecas Please take a look when you get chance |
saswatamcode
left a comment
saswatamcode
left a comment
There was a problem hiding this comment.
Generally LGTM, but some comments
| - Search the returned list to find the exact metric name that exists | ||
|
|
||
| **STEP 2: Call get_label_names for the metric you found** | ||
| **STEP 2 (optional): Call get_label_names for the metric you found** |
There was a problem hiding this comment.
Skipping these would save tool_calls and token, but I think that would end up harming accuracy, as LLM will effectively be guessing labels. For non-platform custom metrics these def shouldn't be optional
|
|
||
| ## QUERY EFFICIENCY | ||
|
|
||
| Write PromQL that answers the question in as few queries as possible. Do NOT query one entity at a time (e.g., one query per pod, per namespace, or per node). Instead, use PromQL aggregation to get all results in a single query. |
There was a problem hiding this comment.
This is great advice for broad questions like top CPU or total reqs on a service.
But I feel like this would work against it, when there would be some incident RCA where it should look per entity/pod level, right?
| - **execute_range_query**: Trends over time, rate calculations, historical analysis` | ||
| - **execute_range_query**: Trends over time, rate calculations, historical analysis | ||
|
|
||
| ## QUERY EFFICIENCY |
There was a problem hiding this comment.
How about renaming to Query Aggregation? :)
2 participants
Add QUERY EFFICIENCY section to ServerPrompt with PromQL aggregation patterns
(topk, sum by, rate) to prevent agents from querying one entity at a time
Details on eval runs in jira
Triggered by evals test cpu-usage from #34