From 89cdf492a8ea580bee93d172054ca67be51baaa6 Mon Sep 17 00:00:00 2001 From: zachary62 Date: Thu, 2 Jan 2025 00:38:18 +0000 Subject: [PATCH] better doc --- docs/async.md | 2 +- docs/communication.md | 12 +++++++----- docs/flow.md | 11 +++++++---- docs/index.md | 6 ++++-- docs/node.md | 1 + 5 files changed, 20 insertions(+), 12 deletions(-) diff --git a/docs/async.md b/docs/async.md index c3cc235..c9d265a 100644 --- a/docs/async.md +++ b/docs/async.md @@ -7,7 +7,7 @@ nav_order: 5 # (Advanced) Async -**Async Nodes** implement `prep_async()`, `exec_async()`, `exec_fallback_async()`, and/or `post_async()`. This is useful for: +**Async** Nodes implement `prep_async()`, `exec_async()`, `exec_fallback_async()`, and/or `post_async()`. This is useful for: 1. **prep_async()** - For *fetching/reading data (files, APIs, DB)* in an I/O-friendly way. diff --git a/docs/communication.md b/docs/communication.md index bd74345..cf9cade 100644 --- a/docs/communication.md +++ b/docs/communication.md @@ -15,9 +15,8 @@ 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. +{: .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. --- @@ -74,11 +73,14 @@ No special data-passing—just the same `shared` object. ## 2. Params -**Params** let you store **per-Node** or **per-Flow** config that doesn’t need to live in the global store. They are: +**Params** let you store *per-Node* or *per-Flow* config that doesn't need to live in the shared store. They are: - **Immutable** during a Node’s run cycle (i.e., they don’t change mid-`prep`, `exec`, `post`). -- **Set** via `set_params()`. **⚠️ 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). +- **Set** via `set_params()`. - **Cleared** and updated each time a parent Flow calls it. +{: .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. ### Example diff --git a/docs/flow.md b/docs/flow.md index 6b6e4db..701fcdd 100644 --- a/docs/flow.md +++ b/docs/flow.md @@ -22,7 +22,7 @@ You define transitions with the syntax: 2. Named action transition: `node_a - "action_name" >> node_b` This means if `node_a.post()` returns `"action_name"`, go to `node_b`. -It’s possible to create loops, branching, or multi-step flows. You can also chain with multiple Actions from a single node to different successors. +It’s possible to create loops, branching, or multi-step flows. ## 2. Creating a Flow @@ -83,10 +83,13 @@ flowchart TD ### Running Individual Nodes vs. Running a Flow -- **`node.run(shared)`**: Just runs that node alone (calls `prep()`, `exec()`, `post()`), returns an Action. ⚠️ **Does not** proceed automatically to the successor and may use incorrect parameters. This is mainly for debugging or testing a single node. -- **`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). +- `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). -Always use `flow.run(...)` in production to ensure the full pipeline runs correctly. +{: .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. ## 3. Nested Flows diff --git a/docs/index.md b/docs/index.md index 6af7bde..ca6a1ce 100644 --- a/docs/index.md +++ b/docs/index.md @@ -31,7 +31,9 @@ We model the LLM workflow as a **Nested Directed Graph**: - [(Advanced) Parallel](./parallel.md) ## Low-Level Details -⚠️ We do not provide + +{: .note } +We do not provide implementation - [LLM Wrapper](./llm.md) - [Tool](./tool.md) @@ -40,9 +42,9 @@ We model the LLM workflow as a **Nested Directed Graph**: - [Structured Output](./structure.md) - Task Decomposition +- Map Reduce - RAG - Chat Memory -- Map Reduce - Agent - Multi-Agent - Evaluation diff --git a/docs/node.md b/docs/node.md index 581388c..19fd7c8 100644 --- a/docs/node.md +++ b/docs/node.md @@ -25,6 +25,7 @@ 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). +{: .note } All 3 steps are optional. For example, you might only need to run the Prep without calling the LLM. ## Fault Tolerance & Retries