> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.
2.**Reducción del Tiempo Hasta el Primer Token**: Los usuarios ven la salida inmediatamente
en lugar de esperar a que se complete la generación.
3.**Manejo de Respuestas Largas**: Maneja salidas muy largas que de otro modo
podrían provocar un tiempo de espera o exceder los límites de memoria.
4.**Aplicaciones Interactivas**: Permite interfaces de chat y agentes receptivas.
## Objetivos
**Compatibilidad con Versiones Anteriores**: Los clientes existentes que no utilizan streaming continúan funcionando
sin modificaciones.
**Diseño de API Consistente**: El streaming y el no streaming utilizan los mismos patrones de esquema
con una divergencia mínima.
**Flexibilidad del Proveedor**: Soporte de streaming cuando esté disponible, con una
alternativa gradual cuando no esté disponible.
**Implementación por Fases**: Implementación incremental para reducir el riesgo.
**Soporte de Extremo a Extremo**: Streaming desde el proveedor de LLM hasta las aplicaciones cliente
a través de Pulsar, la API de Gateway y la API de Python.
## Antecedentes
### Arquitectura Actual
El flujo actual de finalización de texto de LLM funciona de la siguiente manera:
1. El cliente envía `TextCompletionRequest` con los campos `system` y `prompt`.
2. El servicio de LLM procesa la solicitud y espera a que se complete la generación.
3. Se devuelve un único `TextCompletionResponse` con la cadena `response` completa.
Esquema actual (`trustgraph-base/trustgraph/schema/services/llm.py`):
```python
class TextCompletionRequest(Record):
system = String()
prompt = String()
class TextCompletionResponse(Record):
error = Error()
response = String()
in_token = Integer()
out_token = Integer()
model = String()
```
### Limitaciones actuales
**Latencia**: Los usuarios deben esperar a que se complete la generación antes de ver cualquier resultado.
**Riesgo de tiempo de espera**: Las generaciones largas pueden exceder los umbrales de tiempo de espera del cliente.
**Mala experiencia de usuario**: La falta de retroalimentación durante la generación crea la percepción de lentitud.
**Uso de recursos**: Las respuestas completas deben almacenarse en búfer en la memoria.
Esta especificación aborda estas limitaciones al permitir la entrega incremental de respuestas, manteniendo la compatibilidad total con versiones anteriores.
## Diseño técnico
### Fase 1: Infraestructura
La Fase 1 establece la base para la transmisión mediante la modificación de esquemas, API y herramientas de línea de comandos.
#### Cambios en el esquema
##### Esquema de LLM (`trustgraph-base/trustgraph/schema/services/llm.py`)
**Cambios en la solicitud:**
```python
class TextCompletionRequest(Record):
system = String()
prompt = String()
streaming = Boolean() # NEW: Default false for backward compatibility
```
`streaming`: Cuando `true`, solicita la entrega de la respuesta en modo de transmisión.
Predeterminado: `false` (el comportamiento existente se mantiene).
**Cambios en la respuesta:**
```python
class TextCompletionResponse(Record):
error = Error()
response = String()
in_token = Integer()
out_token = Integer()
model = String()
end_of_stream = Boolean() # NEW: Indicates final message
```
`end_of_stream`: Cuando `true`, indica que esta es la respuesta final (o única).
Para solicitudes no de transmisión: Respuesta única con `end_of_stream=true`.
Para solicitudes de transmisión: Múltiples respuestas, todas con `end_of_stream=false`
excepto la última.
##### Esquema de la solicitud (`trustgraph-base/trustgraph/schema/services/prompt.py`)
El servicio de solicitud envuelve la finalización de texto, por lo que refleja el mismo patrón:
**Cambios en la solicitud:**
```python
class PromptRequest(Record):
id = String()
terms = Map(String())
streaming = Boolean() # NEW: Default false
```
**Cambios en la respuesta:**
```python
class PromptResponse(Record):
error = Error()
text = String()
object = String()
end_of_stream = Boolean() # NEW: Indicates final message
```
#### Cambios en la API de Gateway
La API de Gateway debe exponer capacidades de transmisión a clientes HTTP/WebSocket.
**Actualizaciones de la API REST:**
`POST /api/v1/text-completion`: Aceptar el parámetro `streaming` en el cuerpo de la solicitud.
El comportamiento de la respuesta depende de la bandera de transmisión:
`streaming=false`: Respuesta JSON única (comportamiento actual).
`streaming=true`: Flujo de eventos enviados por el servidor (SSE) o mensajes WebSocket.
**Formato de respuesta (transmisión):**
Cada fragmento transmitido sigue la misma estructura de esquema:
```json
{
"response": "partial text...",
"end_of_stream": false,
"model": "model-name"
}
```
Fragmento final:
```json
{
"response": "final text chunk",
"end_of_stream": true,
"in_token": 150,
"out_token": 500,
"model": "model-name"
}
```
#### Cambios en la API de Python
La API del cliente de Python debe soportar tanto modos de transmisión como no de transmisión
manteniendo la compatibilidad con versiones anteriores.
**Actualizaciones de LlmClient** (`trustgraph-base/trustgraph/clients/llm_client.py`):
