gupta-sahil01 opened a new issue, #6293:
URL: https://github.com/apache/texera/issues/6293

   ### Feature Summary
   
   Building a workflow today requires knowing the operator catalog well enough 
to pick the next operator by name. The existing chatbot helps, but only **on 
demand** — the user has to stop and ask. There is no ambient guidance at the 
moment of authoring.
   
   This proposes an **ambient operator recommender**: after an operator is 
added to the canvas, 1–3 faded "ghost" operators appear on its output port 
showing the most likely next operators. Clicking one materializes it and wires 
the link. It behaves like code-completion ghost text, but for dataflow graphs — 
predictive and non-intrusive, never blocking the user.
   
   Design was discussed and agreed in #5240.
   
   | | Existing chatbot | Operator recommender |
   | --- | --- | --- |
   | Trigger | User asks | Operator added to canvas |
   | Mode | Conversational | Ambient, ranked ghosts |
   | Cost | LLM call per turn | Zero in V1; small model in V2 |
   
   ### Proposed Solution or Design
   
   Ship in two versions, as agreed in #5240 (zuozhiw: "the plan sounds good, 
please go ahead with first steps"; xuang7: V1 needs no LLM call, "default 
configuration should be sufficient").
   
   **V1 — hardcoded, zero API cost.** Validates the whole pipeline before 
spending anything on inference.
   
   ```
   canvas: operator added
           │  getOperatorAddStream()
           ▼
   frontend hook ──POST /api/recommend──► agent-service (stateless)
           ◄──── ranked suggestions ─────  hardcoded rule table
           │                               + operator catalog validation
           ▼
   1–3 ghost operators on output port ──click──► materialize + link
   ```
   
   - `POST /api/recommend` in `agent-service`: stateless, no DB, no LLM, no 
user token.
   - Ranks from a small hardcoded successor table keyed on the real operator 
catalog.
   - Suggestions validated against the live catalog (`WorkflowSystemMetadata`), 
so a stale rule degrades to "not suggested" rather than a broken ghost.
   - Response carries a `strategy` discriminator (`"hardcoded"` / `"llm"`) so 
V2 swaps in behind the same request/response shape, no breaking change.
   - Frontend ghost rendering gated behind a new opt-in GUI config flag, 
default off.
   
   **V2 — LLM-backed ranking.** After community feedback on V1.
   
   - Replace the rule table with a small, cheap, openly-available model via the 
existing LiteLLM gateway (custom model training ruled out as infeasible in 
#5240).
   - In-memory caching with auto-eviction; still stateless, still no DB.
   - Add repo-versioned operator descriptions, example workflow patterns, and a 
ranking test set, plus a CI evaluation of ranking quality.
   
   **Scope of this issue** is V1 only, split into two PRs:
   
   | PR | Scope |
   | --- | --- |
   | 1 | `agent-service`: stateless `POST /api/recommend`, hardcoded ranking, 
catalog validation, unit + route tests |
   | 2 | `frontend`: subscribe to operator-added events, ghost rendering on 
output port, click-to-materialize, opt-in config flag |
   
   V2 will be tracked as a follow-up issue.
   
   ### Affected Area
   
   Workflow UI, Other


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to