Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

context-runtime

Context Runtime es un planificador de consultas para contexto de LLM que decide qué información ve el modelo antes de responder. Optimiza la recuperación, compresión y verificación del contexto, aprendiendo de los resultados. Funciona como una capa de decisión dentro de aplicaciones agénticas.

Ficha actualizada 25 sept 2026, 17:31 · upstream 25 sept 2026, 17:20 · release v0.1.0

Ver códigoProblemas y ayudaRepositorio ↗
00

Qué es context-runtime

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

Context Runtime actúa como un planificador de consultas para el contexto de LLM, decidiendo qué información debe ver el modelo antes de generar una respuesta. Analiza la intención, genera candidatos y optimiza la selección basándose en coste y calidad aprendida. Emite planes inspeccionables y reproducibles que pueden ser analizados con comandos EXPLAIN similares a SQL.

El sistema incluye seis puntos de conexión (seams) para planificación, costes, optimización, ejecución, programación y razonamiento. Soporta modelos reales vía LiteLLM o stubs offline. Integra retrieval híbrido (BM25, dense, graph-PPR), compresión semántica con LLMLingua-2 y verificación de citas con RAGAS/Instructor.

La arquitectura reutiliza el sustrato existente de las aplicaciones, actuando como capa de decisión que define qué contexto, herramientas y configuración usar por solicitud. Incluye un ledger de confianza para trazabilidad de aprobaciones humanas y abstenciones fundamentadas.

CASOS DE USO
  • Optimización de sistemas RAG ajustando pool, límite, umbral y reranking por consulta
  • Triage en SOC seleccionando fuentes de alerta (CrowdSec, threat-intel, EDR) con aprobación
  • Gestión de atribución definiendo ventana temporal y bundle de fuentes por lead-source
  • Dashboards Metabase filtrando conjuntos de consultas según intención del usuario
PUNTOS DESTACADOS
  • Calibración de puntuaciones mediante isotonic para estimar P(relevant)
  • Comando EXPLAIN que desglosa calidad/coste por candidato de recuperación
  • Routing de calidad consciente que premia brazos con mejor rendimiento a igual coste
  • Soporte offline completo con stubs y modelos reales vía LiteLLM lazy-import
PRECAUCIONES
  • Los números de recompensa en ejemplos pueden variar con cambios en modelos o datos
  • Observabilidad completa requiere instalar extras para Langfuse/OpenLLMetry-OTel
  • Funcionalidades avanzadas como HippoRAG requieren dependencias adicionales no incluidas por defecto
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU4 vCPUrecomendación inicial
MEMORIA8 GBRAM estimada
DISCO20 GBalmacenamiento base
COMPLEJIDADmediumnivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Docker detectado

Instalar core con pip install -e . antes de añadir litellm o rag. Ejecutar en puerto 8080. Soporta despliegue offline con stubs o con modelos reales vía LiteLLM. Requiere PostgreSQL y S3/MinIO para persistencia. Verificar SPEC.md para contratos de interfaz.

✓Dockerfile
—Compose
—One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
FastAPIPython
SERVICIOS
PostgreSQLS3/MinIO
BASES DE DATOS
PostgreSQL
PUERTOS
8080
06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.