Spaces:
Sleeping
Sleeping
Devi Priya K
commited on
Commit
·
de64ff8
1
Parent(s):
b57423f
Delete orchestrator_data_flow.md
Browse files- orchestrator_data_flow.md +0 -63
orchestrator_data_flow.md
DELETED
|
@@ -1,63 +0,0 @@
|
|
| 1 |
-
Data Flow Breakdown in learning_path_orchestrator
|
| 2 |
-
We follow a structured data pipeline where each step modifies and passes data to the next stage.
|
| 3 |
-
|
| 4 |
-
1️⃣ Define Custom Data Structures
|
| 5 |
-
- Topic (BaseModel) → Represents a single topic with name and description.
|
| 6 |
-
- Topics (BaseModel) → A wrapper around multiple Topic objects (essentially a list of topics).
|
| 7 |
-
- State (TypedDict) → Holds global state, including user input, generated topics, and completed topics.
|
| 8 |
-
- WorkerState (TypedDict) → Holds individual topic assignments for processing.
|
| 9 |
-
|
| 10 |
-
2️⃣ Step-by-Step Data Flow
|
| 11 |
-
|
| 12 |
-
Step 1: Orchestrator Generates Topics
|
| 13 |
-
Input: user_skills and user_goals
|
| 14 |
-
Process: Calls planner.invoke(), which uses an LLM (Groq API) to generate topics.
|
| 15 |
-
Output: A structured Topics object (a list of Topic objects).
|
| 16 |
-
Storage: The topics list is saved inside State.
|
| 17 |
-
Returns: {"topics": study_plan.topics}
|
| 18 |
-
📌 Key Detail:
|
| 19 |
-
The Orchestrator only generates topics and doesn’t process them. It assigns each topic to workers.
|
| 20 |
-
|
| 21 |
-
Step 2: Assign Workers to Each Topic
|
| 22 |
-
Function: assign_workers(state: State)
|
| 23 |
-
Process: Iterates over state["topics"] and assigns each topic to a worker (i.e., llm_call).
|
| 24 |
-
Returns: A list of dispatch instructions, sending each topic to the llm_call function.
|
| 25 |
-
Key Mechanism:
|
| 26 |
-
Uses Send("llm_call", {"topic": t}), which maps each topic to WorkerState.
|
| 27 |
-
📌 Key Detail:
|
| 28 |
-
This step distributes work in parallel across multiple workers, each handling a single topic.
|
| 29 |
-
|
| 30 |
-
Step 3: LLM Call Generates Topic Summaries
|
| 31 |
-
Function: llm_call(state: WorkerState)
|
| 32 |
-
Input: A single topic object (from WorkerState).
|
| 33 |
-
Process:
|
| 34 |
-
Calls the LLM (llm.invoke) with the topic's name and description.
|
| 35 |
-
Generates a summary + resources in markdown format.
|
| 36 |
-
Output:
|
| 37 |
-
{"completed_topics": [topic_summary.content]}
|
| 38 |
-
Storage: The summaries are stored inside completed_topics in State.
|
| 39 |
-
📌 Key Detail:
|
| 40 |
-
Each worker only receives one topic at a time. The WorkerState helps isolate one topic per call instead of processing everything at once.
|
| 41 |
-
|
| 42 |
-
Step 4: Synthesizer Combines Summaries into a Learning Roadmap
|
| 43 |
-
Function: synthesizer(state: State)
|
| 44 |
-
Input: completed_topics list (all processed topics).
|
| 45 |
-
Process: Joins all summaries together into a structured format.
|
| 46 |
-
Output: {"learning_roadmap": learning_roadmap}
|
| 47 |
-
Final Storage: The roadmap is stored inside State.
|
| 48 |
-
📌 Key Detail:
|
| 49 |
-
This step aggregates all topic summaries into a final, structured learning plan.
|
| 50 |
-
|
| 51 |
-
3️⃣ Where Does the Data Go?
|
| 52 |
-
Step Function Input Output Where the Data Goes
|
| 53 |
-
1 orchestrator(state) User skills & goals topics list Stored in State["topics"]
|
| 54 |
-
2 assign_workers(state) Topics list Send("llm_call", {"topic": t}) Sends each topic to llm_call
|
| 55 |
-
3 llm_call(state) A single topic {"completed_topics": [summary]} Appends to State["completed_topics"]
|
| 56 |
-
4 synthesizer(state) completed_topics list learning_roadmap Stores final roadmap in State["learning_roadmap"]
|
| 57 |
-
|
| 58 |
-
📝 Key Takeaways
|
| 59 |
-
- Orchestrator generates the topics based on user_skills and user_goals.
|
| 60 |
-
- Workers process each topic separately (using llm_call).
|
| 61 |
-
- WorkerState ensures only one topic is processed per worker to avoid mixing topics.
|
| 62 |
-
- The synthesizer combines all results into a final structured roadmap.
|
| 63 |
-
- Data flows in a structured manner through State and WorkerState, ensuring modular and parallel execution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|