update the guide
This commit is contained in:
parent
968156004f
commit
c3c7dcaa2b
|
|
@ -8,6 +8,51 @@ nav_order: 1
|
||||||
# LLM System Design Guidance
|
# LLM System Design Guidance
|
||||||
|
|
||||||
|
|
||||||
|
## System Design Steps
|
||||||
|
|
||||||
|
1. **Project Requirements**
|
||||||
|
- Identify the project's core entities, and provide a step-by-step user story.
|
||||||
|
- Define a list of both functional and non-functional requirements.
|
||||||
|
|
||||||
|
2. **Utility Functions**
|
||||||
|
- Determine the utility functions on which this project depends (e.g., for LLM calls, web searches, file handling).
|
||||||
|
- Implement these functions and write basic tests to confirm they work correctly.
|
||||||
|
|
||||||
|
> After this step, don't jump straight into building an LLM system.
|
||||||
|
>
|
||||||
|
> First, make sure you clearly understand the problem by manually solving it using some example inputs.
|
||||||
|
>
|
||||||
|
> It's always easier to first build a solid intuition about the problem and its solution, then focus on automating the process.
|
||||||
|
{: .warning }
|
||||||
|
|
||||||
|
3. **Flow Design**
|
||||||
|
- Build a high-level design of the flow of nodes (for example, using a Mermaid diagram) to automate the solution.
|
||||||
|
- For each node in your flow, specify:
|
||||||
|
- **prep**: How data is accessed or retrieved.
|
||||||
|
- **exec**: The specific utility function to use (ideally one function per node).
|
||||||
|
- **post**: How data is updated or persisted.
|
||||||
|
- Identify potential design patterns, such as Batch, Agent, or RAG.
|
||||||
|
|
||||||
|
4. **Data Structure**
|
||||||
|
- Decide how you will store and update state (in memory for smaller applications or in a database for larger, persistent needs).
|
||||||
|
- If it isn’t straightforward, define data schemas or models detailing how information is stored, accessed, and updated.
|
||||||
|
- As you finalize your data structure, you may need to refine your flow design.
|
||||||
|
|
||||||
|
5. **Implementation**
|
||||||
|
- For each node, implement the **prep**, **exec**, and **post** functions based on the flow design.
|
||||||
|
- Start coding with a simple, direct approach (avoid over-engineering at first).
|
||||||
|
- Add logging throughout the code to facilitate debugging.
|
||||||
|
|
||||||
|
6. **Optimization**
|
||||||
|
- **Prompt Engineering**: Use clear, specific instructions with illustrative examples to reduce ambiguity.
|
||||||
|
- **Task Decomposition**: Break large or complex tasks into manageable, logical steps.
|
||||||
|
|
||||||
|
7. **Reliability**
|
||||||
|
- **Structured Output**: Ensure 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 results are uncertain.
|
||||||
|
|
||||||
|
|
||||||
## Example LLM Project File Structure
|
## Example LLM Project File Structure
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
@ -93,39 +138,3 @@ def test_call_llm():
|
||||||
prompt = "Hello, how are you?"
|
prompt = "Hello, how are you?"
|
||||||
assert call_llm(prompt) is not None
|
assert call_llm(prompt) is not None
|
||||||
```
|
```
|
||||||
|
|
||||||
## System Design Steps
|
|
||||||
|
|
||||||
1. **Project Requirements**
|
|
||||||
- Identify the project's core entities.
|
|
||||||
- Define each functional requirement and map out how these entities interact step by step.
|
|
||||||
|
|
||||||
2. **Utility Functions**
|
|
||||||
- Determine the low-level utility functions you’ll need (e.g., for LLM calls, web searches, file handling).
|
|
||||||
- Implement these functions and write basic tests to confirm they work correctly.
|
|
||||||
|
|
||||||
3. **Flow Design**
|
|
||||||
- Develop a high-level process flow of nodes that meets the project’s requirements.
|
|
||||||
- For each node in your flow:
|
|
||||||
- **prep**: Determine how data is accessed or retrieved.
|
|
||||||
- **exec**: Outline the utility function to be used. Ideally, one utility function per node. Highlight the `utility function` name.
|
|
||||||
- **post**: Handle any final updates or data persistence tasks.
|
|
||||||
- Identify possible decision points for *Node Actions* and data-intensive operations for *Batch* tasks.
|
|
||||||
- Illustrate the flow with a Mermaid diagram.
|
|
||||||
|
|
||||||
4. **Data Structure**
|
|
||||||
- Decide how to store and update state, whether in memory (for smaller applications) or a database (for larger or persistent needs).
|
|
||||||
- Define data schemas or models that detail how information is stored, accessed, and updated.
|
|
||||||
|
|
||||||
5. **Implementation**
|
|
||||||
- For each node, implement the `prep`, `exec`, and `post` functions based on the flow design.
|
|
||||||
- Start coding with a simple, direct approach (avoid over-engineering at first).
|
|
||||||
|
|
||||||
6. **Optimization**
|
|
||||||
- **Prompt Engineering**: Use clear and specific instructions with illustrative examples to reduce ambiguity.
|
|
||||||
- **Task Decomposition**: Break large, complex tasks into manageable, logical steps.
|
|
||||||
|
|
||||||
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