From 35f8b50f530bcd9c926fb4d8752b9a7caf312561 Mon Sep 17 00:00:00 2001 From: zachary62 Date: Thu, 2 Jan 2025 01:25:34 +0000 Subject: [PATCH] enabled callout --- docs/communication.md | 6 ++++-- docs/flow.md | 3 ++- docs/node.md | 4 +++- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/communication.md b/docs/communication.md index 28301ca..ebba2e2 100644 --- a/docs/communication.md +++ b/docs/communication.md @@ -15,8 +15,9 @@ Nodes and Flows **communicate** in two ways: If you know memory management, **Shared Store** is like a **heap** shared across function calls, while **Params** is like a **stack** assigned by parent function calls. + +> **Why not use other communication models like Message Passing?** *Message passing* works well for simple DAGs, but with *nested graphs* (Flows containing Flows, repeated or cyclic calls), routing messages becomes hard to maintain. A shared store keeps the design simple and easy. {: .note } -**Why not use other communication models like Message Passing?** *Message passing* works well for simple DAGs, but with *nested graphs* (Flows containing Flows, repeated or cyclic calls), routing messages becomes hard to maintain. A shared store keeps the design simple and easy. --- @@ -78,8 +79,9 @@ No special data-passing—just the same `shared` object. - **Set** via `set_params()`. - **Cleared** and updated each time a parent Flow calls it. + +> Only set the uppermost Flow params because others will be overwritten by the parent Flow. If you need to set child node params, see [Batch](./batch.md). {: .warning } -Only set the uppermost Flow params because others will be overwritten by the parent Flow. If you need to set child node params, see [Batch](./batch.md). Typically, **Params** are identifiers (e.g., file name, page number). Use them to fetch the task you assigned or write to a specific part of the shared store. diff --git a/docs/flow.md b/docs/flow.md index 701fcdd..6ac6208 100644 --- a/docs/flow.md +++ b/docs/flow.md @@ -86,10 +86,11 @@ flowchart TD - `node.run(shared)`: Just runs that node alone (calls `prep()`, `exec()`, `post()`), returns an Action. - `flow.run(shared)`: Executes from the start node, follows Actions to the next node, and so on until the flow can’t continue (no next node or no next Action). -{: .warning } + > node.run(shared) **does not** proceed automatically to the successor and may use incorrect parameters. > This is mainly for debugging or testing a single node. > Always use `flow.run(...)` in production to ensure the full pipeline runs correctly. +{: .warning } ## 3. Nested Flows diff --git a/docs/node.md b/docs/node.md index 19fd7c8..aeaa61e 100644 --- a/docs/node.md +++ b/docs/node.md @@ -25,8 +25,10 @@ A **Node** is the smallest building block of Mini LLM Flow. Each Node has 3 step - Examples: *finalize outputs, trigger next steps, or log results*. - Returns a **string** to specify the next action (`"default"` if nothing or `None` is returned). + +> All 3 steps are optional. For example, you might only need to run the Prep without calling the LLM. {: .note } -All 3 steps are optional. For example, you might only need to run the Prep without calling the LLM. + ## Fault Tolerance & Retries