update guide
This commit is contained in:
parent
eed7a86efa
commit
238ccf9c0f
|
|
@ -94,30 +94,38 @@ def test_call_llm():
|
||||||
assert call_llm(prompt) is not None
|
assert call_llm(prompt) is not None
|
||||||
```
|
```
|
||||||
|
|
||||||
## System Design Steps:
|
## System Design Steps
|
||||||
|
|
||||||
1. **Understand Requirements**
|
1. **Project Requirements**
|
||||||
- Clarify application objectives.
|
- Identify the project's core entities.
|
||||||
- Determine and implement the necessary utility functions (e.g., for LLMs, web searches, file handling).
|
- Define each functional requirement and map out how these entities interact step by step.
|
||||||
|
|
||||||
2. **High-Level Flow Design**
|
2. **Utility Functions**
|
||||||
- Design the flow on how to use the utility functions to achieve the objectives.
|
- Determine the low-level utility functions you’ll need (e.g., for LLM calls, web searches, file handling).
|
||||||
- Identify possible branching for *Node Action* and data-heavy steps for *Batch*.
|
- Implement these functions and write basic tests to confirm they work correctly.
|
||||||
|
|
||||||
3. **Shared Memory Structure**
|
3. **Flow Design**
|
||||||
- For small apps, in-memory data is sufficient.
|
- Develop a high-level process flow that meets the project’s requirements.
|
||||||
- For larger or persistent needs, use a database.
|
- Specify which utility functions are used at each step.
|
||||||
- Define data schemas or structures and how states are stored or updated.
|
- Identify possible decision points for *Node Actions* and data-intensive operations for *Batch* tasks.
|
||||||
|
- Illustrate the flow with a Mermaid diagram.
|
||||||
|
|
||||||
4. **Implementation**
|
4. **Shared Memory Structure**
|
||||||
- Start with minimal, straightforward code (e.g., avoid heavy type checking initially).
|
- Decide how to store and update state, whether in memory (for smaller applications) or a database (for larger or persistent needs).
|
||||||
- For each node, specify data access (for `prep` and `post`) and data processing (for `exec`).
|
- Define data schemas or models that detail how information is stored, accessed, and updated.
|
||||||
|
|
||||||
5. **Optimization**
|
5. **Implementation**
|
||||||
- *Prompt Engineering:* Provide clear instructions and examples to reduce ambiguity.
|
- Start coding with a simple, direct approach (avoid over-engineering at first).
|
||||||
- *Task Decomposition:* Break complex tasks into manageable steps.
|
- For each node in your flow:
|
||||||
|
- **prep**: Determine how data is accessed or retrieved.
|
||||||
|
- **exec**: Outline the actual processing or logic needed.
|
||||||
|
- **post**: Handle any final updates or data persistence tasks.
|
||||||
|
|
||||||
6. **Reliability**
|
6. **Optimization**
|
||||||
- *Structured Output:* Verify outputs match the desired format, and increase `max_retries`.
|
- **Prompt Engineering**: Use clear and specific instructions with illustrative examples to reduce ambiguity.
|
||||||
- *Test Cases:* Create tests for parts of the flow with clear inputs/outputs.
|
- **Task Decomposition**: Break large, complex tasks into manageable, logical steps.
|
||||||
- *Self-Evaluation:* For unclear areas, add another Node for LLMs to review the results.
|
|
||||||
|
7. **Reliability**
|
||||||
|
- **Structured Output**: Verify outputs conform to the required format. Consider increasing `max_retries` if needed.
|
||||||
|
- **Test Cases**: Develop clear, reproducible tests for each part of the flow.
|
||||||
|
- **Self-Evaluation**: Introduce an additional Node (powered by LLMs) to review outputs when the results are uncertain.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue