155 lines
4.6 KiB
Markdown
155 lines
4.6 KiB
Markdown
---
|
|
id: specialists
|
|
title: Understanding Specialists - Introduction
|
|
description: Learn how specialists use Evie's Library to execute specific tasks
|
|
sidebar_label: Specialists Intro
|
|
sidebar_position: 1
|
|
---
|
|
|
|
# Understanding Specialists - Introduction
|
|
|
|
## Overview
|
|
|
|
Specialists are powerful components in Evie's ecosystem that perform specific activities using information from Evie's Library. Think of specialists as expert assistants, each trained for particular tasks - from answering questions to filling templates or providing specialized support.
|
|
|
|
## How Specialists Work
|
|
|
|
Every specialist follows a structured approach:
|
|
|
|
1. **Information Gathering**: Using one or more retrievers, specialists search Evie's Library for relevant information
|
|
2. **Information Processing**: Retrieved information is processed according to the specialist's specific algorithm
|
|
3. **Task Execution**: The specialist performs its designated task using:
|
|
- Retrieved information
|
|
- Its configuration settings
|
|
- Provided arguments
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
A[User Request] --> B[Specialist]
|
|
B --> C{Process Arguments}
|
|
C --> D[Evaluate Specialist Arguments]
|
|
D --> E[Push Arguments to Retrievers]
|
|
E --> F[Search Library using Retrievers]
|
|
F --> G[Combine Retrieved Information]
|
|
G --> H[Execute Specialist Algorithm]
|
|
H --> I[Return Results]
|
|
|
|
style A fill:#9c2d66,stroke:#333,stroke-width:2px
|
|
style B fill:#423372,stroke:#333,stroke-width:2px
|
|
style I fill:#9c2d66,stroke:#333,stroke-width:2px
|
|
```
|
|
|
|
### Key Components
|
|
|
|
The relationship between specialists and other components is shown in this diagram:
|
|
|
|
```mermaid
|
|
classDiagram
|
|
class Specialist {
|
|
+id: Integer
|
|
+name: String
|
|
+description: Text
|
|
+type: String
|
|
+configuration: JSON
|
|
+arguments: JSON
|
|
+results: JSON
|
|
}
|
|
|
|
class Retriever {
|
|
+id: Integer
|
|
+name: String
|
|
+catalog_id: Integer
|
|
+type: String
|
|
+configuration: JSON
|
|
}
|
|
|
|
Specialist "*" -- "*" Retriever : uses
|
|
note for Specialist "Each specialist can use multiple retrievers"
|
|
note for Retriever "Each retriever can be used by multiple specialists"
|
|
```
|
|
|
|
### Sessions and Interactions
|
|
|
|
Each specialist operates within sessions, managing interactions as shown here:
|
|
|
|
```mermaid
|
|
classDiagram
|
|
class ChatSession {
|
|
+id: Integer
|
|
+session_id: String
|
|
+session_start: DateTime
|
|
+session_end: DateTime
|
|
}
|
|
|
|
class Interaction {
|
|
+id: Integer
|
|
+chat_session_id: Integer
|
|
+specialist_id: Integer
|
|
+specialist_arguments: JSON
|
|
+specialist_results: JSON
|
|
+question_at: DateTime
|
|
+answer_at: DateTime
|
|
}
|
|
|
|
class Specialist {
|
|
+id: Integer
|
|
+name: String
|
|
+type: String
|
|
}
|
|
|
|
ChatSession "1" -- "*" Interaction
|
|
Specialist "1" -- "*" Interaction
|
|
```
|
|
|
|
## Working with Specialists
|
|
|
|
### Configuration & Arguments
|
|
|
|
Specialists use three key data structures:
|
|
|
|
1. **Configuration**
|
|
- Fixed parameters that remain constant during all interactions
|
|
- Defines core behavior settings (e.g., inference parameters)
|
|
- Set during specialist creation
|
|
|
|
2. **Arguments**
|
|
- Variable parameters passed during each interaction
|
|
- Can change between interactions within a session
|
|
- Example: questions or specific task parameters
|
|
|
|
3. **Results**
|
|
- Output structure returned after each interaction
|
|
- Contains the specialist's response or task output
|
|
- Format depends on specialist type
|
|
|
|
### Sessions
|
|
|
|
- Each session is dedicated to one specialist
|
|
- Sessions maintain context across multiple interactions
|
|
- Session boundaries are specialist-specific
|
|
- For Q&A specialists: typically aligned with client communication sessions
|
|
- For task-based specialists: may be bound by task completion
|
|
|
|
### Argument Inheritance
|
|
|
|
Specialists implement an intelligent argument inheritance mechanism:
|
|
|
|
1. Arguments can be defined at both specialist and retriever levels
|
|
2. When argument names match:
|
|
- Specialist arguments take precedence
|
|
- Retriever-specific values can override this if explicitly set
|
|
3. This allows for:
|
|
- Consistent argument handling across retrievers
|
|
- Flexibility when needed for specific retrievers
|
|
|
|
## Current Specialist Types
|
|
|
|
Currently, the main specialist type is the RAG (Retrieval-Augmented Generation) Specialist, focused on question-answering using library content. Additional specialist types are being developed for:
|
|
|
|
- Sales support
|
|
- Template filling
|
|
- Specialized customer support
|
|
- Document analysis
|
|
- And more...
|
|
|
|
Detailed documentation for each specialist type is available in their respective sections. |