1 line
67 KiB
JSON
1 line
67 KiB
JSON
{"repo": "alphadx/texto2sql", "files": {"docs/providers/sdk/deepseek/snippet.java": {"daf2ae45c8d42f7bfd42d23d5d4529db348b3952": {"t": 1785745660.5084648, "n": 588, "h": "ddd22b0c763c67f7", "c": "var client = java.net.http.HttpClient.newHttpClient();\nvar json = \"{\\\"model\\\":\\\"deepseek-chat\\\",\\\"messages\\\":[{\\\"role\\\":\\\"user\\\",\\\"content\\\":\\\"hola\\\"}]}\";\nvar req = java.net.http.HttpRequest.newBuilder(java.net.URI.create(\"https://api.deepseek.com/v1/chat/completions\"))\n .header(\"Content-Type\",\"application/json\")\n .header(\"Authorization\",\"Bearer \" + System.getenv(\"DEEPSEEK_API_KEY\"))\n .POST(java.net.http.HttpRequest.BodyPublishers.ofString(json))\n .build();\nvar resp = client.send(req, java.net.http.HttpResponse.BodyHandlers.ofString());\nSystem.out.println(resp.body());\n"}, "ef2af40a1376f890f793fe507971c8e3d0debda9": {"t": 1785755498.6577642, "n": 588, "h": "ddd22b0c763c67f7", "c": "var client = java.net.http.HttpClient.newHttpClient();\nvar json = \"{\\\"model\\\":\\\"deepseek-chat\\\",\\\"messages\\\":[{\\\"role\\\":\\\"user\\\",\\\"content\\\":\\\"hola\\\"}]}\";\nvar req = java.net.http.HttpRequest.newBuilder(java.net.URI.create(\"https://api.deepseek.com/v1/chat/completions\"))\n .header(\"Content-Type\",\"application/json\")\n .header(\"Authorization\",\"Bearer \" + System.getenv(\"DEEPSEEK_API_KEY\"))\n .POST(java.net.http.HttpRequest.BodyPublishers.ofString(json))\n .build();\nvar resp = client.send(req, java.net.http.HttpResponse.BodyHandlers.ofString());\nSystem.out.println(resp.body());\n"}}, "docs/providers/sdk/deepseek/snippet.cs": {"daf2ae45c8d42f7bfd42d23d5d4529db348b3952": {"t": 1785745799.6639667, "n": 580, "h": "227b6d0d6e7c4b36", "c": "using System.Net.Http.Headers;\nusing System.Text;\nusing System.Text.Json;\n\nusing var http = new HttpClient();\nhttp.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(\"Bearer\", Environment.GetEnvironmentVariable(\"DEEPSEEK_API_KEY\"));\nvar body = JsonSerializer.Serialize(new { model = \"deepseek-chat\", messages = new[] { new { role = \"user\", content = \"hola\" } } });\nvar res = await http.PostAsync(\"https://api.deepseek.com/v1/chat/completions\", new StringContent(body, Encoding.UTF8, \"application/json\"));\nConsole.WriteLine(await res.Content.ReadAsStringAsync());\n"}, "ef2af40a1376f890f793fe507971c8e3d0debda9": {"t": 1785755500.3127918, "n": 580, "h": "227b6d0d6e7c4b36", "c": "using System.Net.Http.Headers;\nusing System.Text;\nusing System.Text.Json;\n\nusing var http = new HttpClient();\nhttp.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(\"Bearer\", Environment.GetEnvironmentVariable(\"DEEPSEEK_API_KEY\"));\nvar body = JsonSerializer.Serialize(new { model = \"deepseek-chat\", messages = new[] { new { role = \"user\", content = \"hola\" } } });\nvar res = await http.PostAsync(\"https://api.deepseek.com/v1/chat/completions\", new StringContent(body, Encoding.UTF8, \"application/json\"));\nConsole.WriteLine(await res.Content.ReadAsStringAsync());\n"}}, "docs/README.md": {"daf2ae45c8d42f7bfd42d23d5d4529db348b3952": {"t": 1785747226.802557, "n": 10638, "h": "29c7d04a1cc5ca02", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n> Referencia operativa adicional: `docs/operacion/ejemplos-documentos-llm.md` (8 documentos tipo y etapa de construcción de ejemplos).\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe deja explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible.\n\n> Alcance actual: este backlog documenta trabajo pendiente de producto/arquitectura; no implica soporte GA hasta cerrar criterios mínimos por proveedor.\n\n- [x] **DeepSeek**: integración inicial por compatibilidad OpenAI completada (pendiente evolución a cliente nativo solo si aparece brecha funcional).\n- [x] **Hugging Face Inference**: integración v1 completada (serverless + dedicated endpoint en modo OpenAI-compatible; evolución futura a capacidades nativas según necesidad).\n- [x] **Gemini (Google)**: integración v1 completada (gateway nativo `generateContent`, mapeo de prompts y soporte por request/env).\n- [x] **Mistral**: integración v1 completada (OpenAI-compatible `chat/completions` con soporte por request/env y validación de configuración).\n- [x] **Claude (Anthropic)**: integración v1 completada (gateway nativo `messages`, alias `claude` y soporte por request/env con validación de configuración).\n- [x] **Llama** (proveedores comerciales/hosted): integración v1 completada (OpenAI-compatible hosted con soporte por request/env y validación de configuración).\n- [x] **Copilot** (escenario enterprise): integración v1 completada (OpenAI-compatible con enfoque enterprise, soporte request/env y validación de configuración).\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n\n## 18) Gobernanza de cambios del Demo\n\nPara cambios que impacten el demo (contrato API, UX o smokes), usar:\n\n- Proceso de change management: `docs/demo-change-management.md`\n- Plantilla PR con sección obligatoria **Impacto en DEMO**: `.github/pull_request_template.md`\n\nEsto permite declarar releases como **Demo Compatible** con evidencia verificable.\n\n## 19) Iniciativa nueva: skill de onboarding + Qwen/Kimi\n\nSe añadió roadmap de **Hito 0 (alineación)** para:\n\n- crear una skill reusable de onboarding de nuevos proveedores LLM,\n- integrar Qwen,\n- e integrar Kimi.\n\nDocumento: `docs/tarea/otros_modelos_llm/provider-onboarding-skill-roadmap.md`.\n\nEstado actual de la iniciativa:\n\n- [x] Qwen: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n- [x] Kimi: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n\nEstado de verificación consolidado: `docs/tarea/otros_modelos_llm/README.md`.\n\n\n## 20) Iniciativa nueva: Xinghuo + Doubao + Zhipu + MiniMax + Pangu + Grok\n\nSe añadió el **Hito 0 (análisis y definición de hitos)** para una nueva ola de integración multi-proveedor:\n\n- Xinghuo\n- Doubao\n- Zhipu\n- MiniMax\n- Pangu\n- Grok\n\nDocumento base: `docs/tarea/otros_modelos_llm/hito0-roadmap-xinghuo-doubao-zhipu-minimax-pangu-grok.md`.\n\nEstado inicial:\n\n- [x] Hito 1 — Diseño técnico transversal\n - Documento: `docs/tarea/otros_modelos_llm/hito1-diseno-tecnico-transversal.md`\n- [x] Hito 2 — Xinghuo\n - Documento: `docs/tarea/otros_modelos_llm/hito2-xinghuo-implementacion.md`\n- [x] Hito 3 — Doubao\n - Documento: `docs/tarea/otros_modelos_llm/hito3-doubao-implementacion.md`\n- [x] Hito 4 — Zhipu + MiniMax\n - Documento: `docs/tarea/otros_modelos_llm/hito4-zhipu-minimax-implementacion.md`\n- [x] Hito 5 — Pangu + Grok\n - Documento: `docs/tarea/otros_modelos_llm/hito5-pangu-grok-implementacion.md`\n- [x] Hito 6 — Cierre y consolidación\n - Documento: `docs/tarea/otros_modelos_llm/hito6-cierre-consolidacion.md`\n"}, "5dca54bd01c48d5cc92f40ec40b0bf6762bee15d": {"t": 1785755499.1944458, "n": 10638, "h": "29c7d04a1cc5ca02", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n> Referencia operativa adicional: `docs/operacion/ejemplos-documentos-llm.md` (8 documentos tipo y etapa de construcción de ejemplos).\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe deja explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible.\n\n> Alcance actual: este backlog documenta trabajo pendiente de producto/arquitectura; no implica soporte GA hasta cerrar criterios mínimos por proveedor.\n\n- [x] **DeepSeek**: integración inicial por compatibilidad OpenAI completada (pendiente evolución a cliente nativo solo si aparece brecha funcional).\n- [x] **Hugging Face Inference**: integración v1 completada (serverless + dedicated endpoint en modo OpenAI-compatible; evolución futura a capacidades nativas según necesidad).\n- [x] **Gemini (Google)**: integración v1 completada (gateway nativo `generateContent`, mapeo de prompts y soporte por request/env).\n- [x] **Mistral**: integración v1 completada (OpenAI-compatible `chat/completions` con soporte por request/env y validación de configuración).\n- [x] **Claude (Anthropic)**: integración v1 completada (gateway nativo `messages`, alias `claude` y soporte por request/env con validación de configuración).\n- [x] **Llama** (proveedores comerciales/hosted): integración v1 completada (OpenAI-compatible hosted con soporte por request/env y validación de configuración).\n- [x] **Copilot** (escenario enterprise): integración v1 completada (OpenAI-compatible con enfoque enterprise, soporte request/env y validación de configuración).\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n\n## 18) Gobernanza de cambios del Demo\n\nPara cambios que impacten el demo (contrato API, UX o smokes), usar:\n\n- Proceso de change management: `docs/demo-change-management.md`\n- Plantilla PR con sección obligatoria **Impacto en DEMO**: `.github/pull_request_template.md`\n\nEsto permite declarar releases como **Demo Compatible** con evidencia verificable.\n\n## 19) Iniciativa nueva: skill de onboarding + Qwen/Kimi\n\nSe añadió roadmap de **Hito 0 (alineación)** para:\n\n- crear una skill reusable de onboarding de nuevos proveedores LLM,\n- integrar Qwen,\n- e integrar Kimi.\n\nDocumento: `docs/tarea/otros_modelos_llm/provider-onboarding-skill-roadmap.md`.\n\nEstado actual de la iniciativa:\n\n- [x] Qwen: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n- [x] Kimi: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n\nEstado de verificación consolidado: `docs/tarea/otros_modelos_llm/README.md`.\n\n\n## 20) Iniciativa nueva: Xinghuo + Doubao + Zhipu + MiniMax + Pangu + Grok\n\nSe añadió el **Hito 0 (análisis y definición de hitos)** para una nueva ola de integración multi-proveedor:\n\n- Xinghuo\n- Doubao\n- Zhipu\n- MiniMax\n- Pangu\n- Grok\n\nDocumento base: `docs/tarea/otros_modelos_llm/hito0-roadmap-xinghuo-doubao-zhipu-minimax-pangu-grok.md`.\n\nEstado inicial:\n\n- [x] Hito 1 — Diseño técnico transversal\n - Documento: `docs/tarea/otros_modelos_llm/hito1-diseno-tecnico-transversal.md`\n- [x] Hito 2 — Xinghuo\n - Documento: `docs/tarea/otros_modelos_llm/hito2-xinghuo-implementacion.md`\n- [x] Hito 3 — Doubao\n - Documento: `docs/tarea/otros_modelos_llm/hito3-doubao-implementacion.md`\n- [x] Hito 4 — Zhipu + MiniMax\n - Documento: `docs/tarea/otros_modelos_llm/hito4-zhipu-minimax-implementacion.md`\n- [x] Hito 5 — Pangu + Grok\n - Documento: `docs/tarea/otros_modelos_llm/hito5-pangu-grok-implementacion.md`\n- [x] Hito 6 — Cierre y consolidación\n - Documento: `docs/tarea/otros_modelos_llm/hito6-cierre-consolidacion.md`\n"}, "4885d58dcc840ace3499bff88b7ffc85ffe31f87": {"t": 1785755500.6336002, "n": 10502, "h": "49e2c4b2a8d20d20", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe deja explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible.\n\n> Alcance actual: este backlog documenta trabajo pendiente de producto/arquitectura; no implica soporte GA hasta cerrar criterios mínimos por proveedor.\n\n- [x] **DeepSeek**: integración inicial por compatibilidad OpenAI completada (pendiente evolución a cliente nativo solo si aparece brecha funcional).\n- [x] **Hugging Face Inference**: integración v1 completada (serverless + dedicated endpoint en modo OpenAI-compatible; evolución futura a capacidades nativas según necesidad).\n- [x] **Gemini (Google)**: integración v1 completada (gateway nativo `generateContent`, mapeo de prompts y soporte por request/env).\n- [x] **Mistral**: integración v1 completada (OpenAI-compatible `chat/completions` con soporte por request/env y validación de configuración).\n- [x] **Claude (Anthropic)**: integración v1 completada (gateway nativo `messages`, alias `claude` y soporte por request/env con validación de configuración).\n- [x] **Llama** (proveedores comerciales/hosted): integración v1 completada (OpenAI-compatible hosted con soporte por request/env y validación de configuración).\n- [x] **Copilot** (escenario enterprise): integración v1 completada (OpenAI-compatible con enfoque enterprise, soporte request/env y validación de configuración).\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n\n## 18) Gobernanza de cambios del Demo\n\nPara cambios que impacten el demo (contrato API, UX o smokes), usar:\n\n- Proceso de change management: `docs/demo-change-management.md`\n- Plantilla PR con sección obligatoria **Impacto en DEMO**: `.github/pull_request_template.md`\n\nEsto permite declarar releases como **Demo Compatible** con evidencia verificable.\n\n## 19) Iniciativa nueva: skill de onboarding + Qwen/Kimi\n\nSe añadió roadmap de **Hito 0 (alineación)** para:\n\n- crear una skill reusable de onboarding de nuevos proveedores LLM,\n- integrar Qwen,\n- e integrar Kimi.\n\nDocumento: `docs/tarea/otros_modelos_llm/provider-onboarding-skill-roadmap.md`.\n\nEstado actual de la iniciativa:\n\n- [x] Qwen: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n- [x] Kimi: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n\nEstado de verificación consolidado: `docs/tarea/otros_modelos_llm/README.md`.\n\n\n## 20) Iniciativa nueva: Xinghuo + Doubao + Zhipu + MiniMax + Pangu + Grok\n\nSe añadió el **Hito 0 (análisis y definición de hitos)** para una nueva ola de integración multi-proveedor:\n\n- Xinghuo\n- Doubao\n- Zhipu\n- MiniMax\n- Pangu\n- Grok\n\nDocumento base: `docs/tarea/otros_modelos_llm/hito0-roadmap-xinghuo-doubao-zhipu-minimax-pangu-grok.md`.\n\nEstado inicial:\n\n- [x] Hito 1 — Diseño técnico transversal\n - Documento: `docs/tarea/otros_modelos_llm/hito1-diseno-tecnico-transversal.md`\n- [x] Hito 2 — Xinghuo\n - Documento: `docs/tarea/otros_modelos_llm/hito2-xinghuo-implementacion.md`\n- [x] Hito 3 — Doubao\n - Documento: `docs/tarea/otros_modelos_llm/hito3-doubao-implementacion.md`\n- [x] Hito 4 — Zhipu + MiniMax\n - Documento: `docs/tarea/otros_modelos_llm/hito4-zhipu-minimax-implementacion.md`\n- [x] Hito 5 — Pangu + Grok\n - Documento: `docs/tarea/otros_modelos_llm/hito5-pangu-grok-implementacion.md`\n- [x] Hito 6 — Cierre y consolidación\n - Documento: `docs/tarea/otros_modelos_llm/hito6-cierre-consolidacion.md`\n"}, "7452c70d422f4067bab425a2766d09d9bb0fba49": {"t": 1785755502.8386652, "n": 9487, "h": "cd70ec9903015f4f", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe deja explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible.\n\n> Alcance actual: este backlog documenta trabajo pendiente de producto/arquitectura; no implica soporte GA hasta cerrar criterios mínimos por proveedor.\n\n- [x] **DeepSeek**: integración inicial por compatibilidad OpenAI completada (pendiente evolución a cliente nativo solo si aparece brecha funcional).\n- [x] **Hugging Face Inference**: integración v1 completada (serverless + dedicated endpoint en modo OpenAI-compatible; evolución futura a capacidades nativas según necesidad).\n- [x] **Gemini (Google)**: integración v1 completada (gateway nativo `generateContent`, mapeo de prompts y soporte por request/env).\n- [x] **Mistral**: integración v1 completada (OpenAI-compatible `chat/completions` con soporte por request/env y validación de configuración).\n- [x] **Claude (Anthropic)**: integración v1 completada (gateway nativo `messages`, alias `claude` y soporte por request/env con validación de configuración).\n- [x] **Llama** (proveedores comerciales/hosted): integración v1 completada (OpenAI-compatible hosted con soporte por request/env y validación de configuración).\n- [x] **Copilot** (escenario enterprise): integración v1 completada (OpenAI-compatible con enfoque enterprise, soporte request/env y validación de configuración).\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n\n## 18) Gobernanza de cambios del Demo\n\nPara cambios que impacten el demo (contrato API, UX o smokes), usar:\n\n- Proceso de change management: `docs/demo-change-management.md`\n- Plantilla PR con sección obligatoria **Impacto en DEMO**: `.github/pull_request_template.md`\n\nEsto permite declarar releases como **Demo Compatible** con evidencia verificable.\n\n## 19) Iniciativa nueva: skill de onboarding + Qwen/Kimi\n\nSe añadió roadmap de **Hito 0 (alineación)** para:\n\n- crear una skill reusable de onboarding de nuevos proveedores LLM,\n- integrar Qwen,\n- e integrar Kimi.\n\nDocumento: `docs/tarea/integración_llm_varios/provider-onboarding-skill-roadmap.md`.\n\nEstado actual de la iniciativa:\n\n- [x] Qwen: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n- [x] Kimi: integración v1 completada (OpenAI-compatible hosted con soporte request/env y validación).\n\nEstado de verificación consolidado: `docs/tarea/integración_llm_varios/README.md`.\n"}, "1a1cb250c5f72547118daaa36d2aaf30867db0a8": {"t": 1785755504.1506534, "n": 8357, "h": "e28dcac0d20f74d7", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe acuerda dejar explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible:\n\n- [ ] **DeepSeek**: definir cliente oficial o compatibilidad OpenAI, variables de entorno y catálogo de modelos.\n- [ ] **Hugging Face Inference**: definir integración (serverless/dedicated endpoint), autenticación y límites.\n- [ ] **Gemini (Google)**: agregar cliente/API, mapeo de modelos y estrategia de prompts equivalente.\n- [ ] **Mistral**: soporte de SDK/endpoint y configuración por entorno + request.\n- [ ] **Claude (Anthropic)**: cliente dedicado, manejo de mensajes y compatibilidad con el flujo de 2 agentes.\n- [ ] **Llama** (proveedores comerciales/hosted): definir variantes soportadas y endpoint objetivo.\n- [ ] **Copilot** (escenario enterprise): evaluar alcance técnico real para uso como backend programático.\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n\n## 18) Gobernanza de cambios del Demo\n\nPara cambios que impacten el demo (contrato API, UX o smokes), usar:\n\n- Proceso de change management: `docs/demo-change-management.md`\n- Plantilla PR con sección obligatoria **Impacto en DEMO**: `.github/pull_request_template.md`\n\nEsto permite declarar releases como **Demo Compatible** con evidencia verificable.\n"}, "ef2af40a1376f890f793fe507971c8e3d0debda9": {"t": 1785755505.6516476, "n": 8003, "h": "8480bcc678df945b", "c": "# Documentación de LLM comerciales y configuración de API keys\n\nEste documento resume **qué modelos/proveedores LLM comerciales** soporta el proyecto hoy y **cómo se configuran las API keys** tanto por entorno como por request.\n\n## 1) Resumen rápido\n\n- El backend usa el SDK de `openai` y un cliente `OpenAI(...)` configurable con `base_url`, por lo que opera como **OpenAI-compatible API**.\n- El proveedor por defecto es `openai`.\n- El modelo por defecto en runtime es `gpt-4`.\n- Se puede sobreescribir proveedor/modelo/key/base_url por cada request en `POST /nl2sql/query`.\n\n## 2) Qué LLM comerciales están disponibles en el código\n\nActualmente, el código implementa integración directa con un cliente OpenAI-compatible:\n\n- **Proveedor lógico**: `openai` (default).\n- **Modelos**: cualquier modelo aceptado por el endpoint OpenAI-compatible configurado en `OPENAI_BASE_URL`.\n - Ejemplos visibles en el proyecto:\n - `gpt-4` (default en `resolve_llm_config`).\n - `gpt-4.1-mini` (ejemplo en el schema de request).\n\n> Nota: El campo `llm_provider` existe y se transporta en request, pero el cliente concreto se construye con `OpenAI(...)`; por eso, para otros proveedores comerciales se espera un endpoint compatible o adaptación futura del código.\n\n## 3) Configuración principal por variables de entorno\n\nLas variables de entorno oficiales para el motor LLM son:\n\n- `LLM_PROVIDER`\n- `OPENAI_API_KEY`\n- `OPENAI_MODEL`\n- `OPENAI_BASE_URL`\n\nFlujo de resolución en backend (`app/llm/converter.py`):\n\n1. Toma primero los overrides de `llm_options` (request).\n2. Si no existen, usa variables de entorno.\n3. Si falta API key, lanza error de runtime.\n\n## 4) Overrides por request (runtime)\n\nEl endpoint `POST /nl2sql/query` permite enviar:\n\n- `llm_provider`\n- `llm_model`\n- `llm_api_key`\n- `llm_base_url`\n\nEsto habilita escenarios multi-tenant o pruebas de proveedor/modelo sin tocar el `.env` global.\n\n## 5) Variables usadas en demo/UI\n\nEl demo (`demo/app/public/chat.php`) consume parámetros runtime y/o env para reenviarlos al backend:\n\n- `NL2SQL_API_PROVIDER` → `llm_provider`\n- `NL2SQL_MODEL` → `llm_model`\n- `LLM_API_KEY` → `llm_api_key`\n- `LLM_BASE_URL` → `llm_base_url`\n\nAdemás, puede incluir un bearer para la API principal con `NL2SQL_API_KEY`.\n\n## 6) Archivos clave para mantener esta integración\n\n- `app/llm/converter.py`: resolución de config LLM y cliente OpenAI-compatible.\n- `app/api.py`: schema de request con campos `llm_*` y construcción de `llm_options`.\n- `README.md`: guía de instalación principal y variables oficiales.\n- `demo/app/public/chat.php`: mapeo de variables/env del demo hacia payload `llm_*`.\n\n## 7) Recomendaciones de documentación futura\n\nSi se agrega soporte nativo para otros proveedores comerciales (Anthropic, Gemini, etc.), documentar explícitamente:\n\n1. SDK/cliente usado por proveedor.\n2. Variables de entorno por proveedor.\n3. Modelos validados/oficialmente soportados.\n4. Reglas de precedencia entre `.env` y overrides por request.\n\n## 8) TODO de implementación (pendiente)\n\nSe acuerda dejar explícito el backlog para ampliar proveedores/modelos más allá de OpenAI-compatible:\n\n- [ ] **DeepSeek**: definir cliente oficial o compatibilidad OpenAI, variables de entorno y catálogo de modelos.\n- [ ] **Hugging Face Inference**: definir integración (serverless/dedicated endpoint), autenticación y límites.\n- [ ] **Gemini (Google)**: agregar cliente/API, mapeo de modelos y estrategia de prompts equivalente.\n- [ ] **Mistral**: soporte de SDK/endpoint y configuración por entorno + request.\n- [ ] **Claude (Anthropic)**: cliente dedicado, manejo de mensajes y compatibilidad con el flujo de 2 agentes.\n- [ ] **Llama** (proveedores comerciales/hosted): definir variantes soportadas y endpoint objetivo.\n- [ ] **Copilot** (escenario enterprise): evaluar alcance técnico real para uso como backend programático.\n\n### Criterios mínimos para cerrar cada TODO\n\n1. Variables nuevas documentadas en `.env.example` o guía equivalente.\n2. Validación de configuración (`api_key`, `model`, `base_url`) en backend.\n3. Ejemplo funcional en `POST /nl2sql/query` usando `llm_*` por request.\n4. Pruebas mínimas (unit/integración) para resolución de configuración y llamada al proveedor.\n\n## 9) Configuración operativa centralizada (resiliencia)\n\nPara operación estable multi-proveedor, la capa LLM ahora contempla parámetros globales:\n\n- `LLM_MAX_RETRIES`: reintentos por llamada cuando hay fallos transitorios.\n- `LLM_RETRY_BACKOFF_SECONDS`: backoff base (exponencial) entre reintentos.\n- `LLM_HTTP_TIMEOUT_SECONDS`: timeout HTTP para gateways nativos.\n- `LLM_CIRCUIT_BREAKER_FAILURE_THRESHOLD`: fallos consecutivos para abrir circuito por proveedor.\n- `LLM_CIRCUIT_BREAKER_RESET_SECONDS`: ventana antes de permitir intentos de recuperación.\n\nAdemás de:\n\n- `LLM_PROVIDER`, `LLM_API_KEY`, `LLM_MODEL`, `LLM_BASE_URL` (defaults globales),\n- y el fallback por proveedor con `<PROVIDER>_API_KEY`, `<PROVIDER>_MODEL`, `<PROVIDER>_BASE_URL`.\n\n### Matriz rápida por proveedor (actual)\n\n- **OpenAI / DeepSeek / Mistral / HuggingFace / Llama / Copilot**: ruta OpenAI-compatible.\n- **Anthropic**: gateway nativo `messages`.\n- **Gemini**: gateway nativo `generateContent`.\n\n## 10) Hito de guías por compañía (multi-lenguaje)\n\nSe creó un paquete de documentación por compañía con enfoque en modelo mini/equivalente y snippets compatibles con:\n\n- PHP 8.3\n- Node.js (LTS actual)\n- Python (estable actual)\n- C++ (estándar actual + libcurl)\n- C# (.NET actual)\n- Java (JDK actual)\n\nÍndice: `docs/providers/README.md`.\n\n## 11) Hito de configuración central (`.env.example` + validación de arranque)\n\nSe añadió `.env.example` con:\n\n- variables base de auth,\n- defaults LLM,\n- API keys por proveedor,\n- y parámetros de resiliencia.\n\nTambién se incorporó validación de settings LLM al arranque de la API:\n\n- `LLM_PROVIDER` debe ser soportado,\n- parámetros de resiliencia deben tener rangos válidos,\n- si `LLM_STARTUP_VALIDATE=true`, la API key debe existir al iniciar.\n\n## 12) Hito de smoke-test por proveedor (CI + script)\n\nSe añadió:\n\n- script `scripts/llm_provider_smoke.py` (modo `--dry-run` y modo live),\n- target `make llm-smoke-dry`,\n- job de CI con matriz de proveedores para validar wiring de configuración/gateway sin llamadas reales.\n\n## 13) Hito final: matriz de compatibilidad + checklist de producción\n\nSe añadieron dos documentos operativos:\n\n- `docs/providers/compatibility-matrix.md`: matriz por proveedor/lenguaje/modelo mini-equivalente.\n- `docs/providers/production-checklist.md`: checklist de despliegue por compañía.\n\n## 14) Hito extra: catálogo JSON para automatización\n\nSe añadió `docs/providers/catalog.json` como fuente machine-readable con:\n\n- proveedor,\n- compañía,\n- modelo mini/equivalente,\n- variable de API key,\n- endpoint base,\n- y ruta del markdown asociado.\n\nAdemás:\n\n- script `scripts/validate_provider_catalog.py` para validar integridad del catálogo,\n- test automatizado en `tests/test_provider_catalog_validator.py`,\n- y job de CI `provider-catalog-validate`.\n\n## 15) Hito extra: generación automática de artefactos de docs\n\nSe añadió `scripts/generate_provider_artifacts.py` para generar desde `catalog.json`:\n\n- `docs/providers/compatibility-matrix.md`\n- `docs/providers/snippets-index.md`\n\nCon validación de sincronía en CI (`provider-artifacts-sync`).\n\n## 16) Hito extra: generación de markdowns por proveedor desde catálogo\n\nSe añadieron:\n\n- `scripts/generate_provider_markdowns.py` para regenerar `docs/providers/*.md` desde `catalog.json`.\n- `scripts/validate_provider_docs.py` para validar consistencia catálogo ↔ markdown.\n- job CI `provider-markdown-sync` para exigir sincronía.\n\n## 17) Hito de cierre completo: snippets typed + validación CI\n\nSe añadieron:\n\n- `scripts/generate_typed_snippets.py` para generar snippets por proveedor/lenguaje en `docs/providers/sdk/`.\n- `scripts/validate_typed_snippets.py` para validar estructura y contenido base.\n- job CI `typed-snippets-sync` para generar, validar y comprobar sincronía (`git diff --exit-code`).\n"}}, "docs/providers/catalog.json": {"daf2ae45c8d42f7bfd42d23d5d4529db348b3952": {"t": 1785809851.5785396, "n": 4279, "h": "80d69d901f4e9b38", "c": "{\n \"schema_version\": 1,\n \"languages\": [\n \"php_8_3\",\n \"nodejs_lts\",\n \"python_stable\",\n \"cpp_libcurl\",\n \"csharp_dotnet\",\n \"java_jdk\"\n ],\n \"providers\": [\n {\n \"id\": \"openai\",\n \"company\": \"OpenAI\",\n \"mini_model\": \"gpt-4.1-mini\",\n \"env_api_key\": \"OPENAI_API_KEY\",\n \"base_url\": \"https://api.openai.com/v1/chat/completions\",\n \"doc\": \"docs/providers/openai.md\"\n },\n {\n \"id\": \"deepseek\",\n \"company\": \"DeepSeek\",\n \"mini_model\": \"deepseek-chat\",\n \"env_api_key\": \"DEEPSEEK_API_KEY\",\n \"base_url\": \"https://api.deepseek.com/v1/chat/completions\",\n \"doc\": \"docs/providers/deepseek.md\"\n },\n {\n \"id\": \"huggingface\",\n \"company\": \"Hugging Face\",\n \"mini_model\": \"Qwen/Qwen2.5-3B-Instruct\",\n \"env_api_key\": \"HUGGINGFACE_API_KEY\",\n \"base_url\": \"https://router.huggingface.co/v1/chat/completions\",\n \"doc\": \"docs/providers/huggingface.md\"\n },\n {\n \"id\": \"gemini\",\n \"company\": \"Google\",\n \"mini_model\": \"gemini-2.0-flash-lite\",\n \"env_api_key\": \"GEMINI_API_KEY\",\n \"base_url\": \"https://generativelanguage.googleapis.com/v1beta/models/{MODEL}:generateContent?key={API_KEY}\",\n \"doc\": \"docs/providers/gemini.md\"\n },\n {\n \"id\": \"mistral\",\n \"company\": \"Mistral\",\n \"mini_model\": \"mistral-small-latest\",\n \"env_api_key\": \"MISTRAL_API_KEY\",\n \"base_url\": \"https://api.mistral.ai/v1/chat/completions\",\n \"doc\": \"docs/providers/mistral.md\"\n },\n {\n \"id\": \"claude\",\n \"company\": \"Anthropic\",\n \"mini_model\": \"claude-3-5-haiku-latest\",\n \"env_api_key\": \"ANTHROPIC_API_KEY\",\n \"base_url\": \"https://api.anthropic.com/v1/messages\",\n \"doc\": \"docs/providers/claude.md\"\n },\n {\n \"id\": \"qwen\",\n \"company\": \"Alibaba Cloud\",\n \"mini_model\": \"qwen-plus\",\n \"env_api_key\": \"QWEN_API_KEY\",\n \"base_url\": \"https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions\",\n \"doc\": \"docs/providers/qwen.md\"\n },\n {\n \"id\": \"kimi\",\n \"company\": \"Moonshot AI\",\n \"mini_model\": \"kimi-k2\",\n \"env_api_key\": \"KIMI_API_KEY\",\n \"base_url\": \"https://api.moonshot.cn/v1/chat/completions\",\n \"doc\": \"docs/providers/kimi.md\"\n },\n {\n \"id\": \"llama\",\n \"company\": \"Meta\",\n \"mini_model\": \"meta-llama/Llama-3.1-8B-Instruct\",\n \"env_api_key\": \"LLAMA_API_KEY\",\n \"base_url\": \"https://router.huggingface.co/v1/chat/completions\",\n \"doc\": \"docs/providers/llama.md\"\n },\n {\n \"id\": \"copilot\",\n \"company\": \"GitHub\",\n \"mini_model\": \"gpt-4.1-mini\",\n \"env_api_key\": \"COPILOT_API_KEY\",\n \"base_url\": \"https://models.inference.ai.azure.com/chat/completions\",\n \"doc\": \"docs/providers/copilot.md\"\n },\n {\n \"id\": \"xinghuo\",\n \"company\": \"iFlytek\",\n \"mini_model\": \"generalv3.5\",\n \"env_api_key\": \"XINGHUO_API_KEY\",\n \"base_url\": \"https://spark-api-open.xf-yun.com/v1/chat/completions\",\n \"doc\": \"docs/providers/xinghuo.md\"\n },\n {\n \"id\": \"doubao\",\n \"company\": \"ByteDance\",\n \"mini_model\": \"doubao-pro-32k\",\n \"env_api_key\": \"DOUBAO_API_KEY\",\n \"base_url\": \"https://ark.cn-beijing.volces.com/api/v3/chat/completions\",\n \"doc\": \"docs/providers/doubao.md\"\n },\n {\n \"id\": \"zhipu\",\n \"company\": \"Zhipu AI\",\n \"mini_model\": \"glm-4-flash\",\n \"env_api_key\": \"ZHIPU_API_KEY\",\n \"base_url\": \"https://open.bigmodel.cn/api/paas/v4/chat/completions\",\n \"doc\": \"docs/providers/zhipu.md\"\n },\n {\n \"id\": \"minimax\",\n \"company\": \"MiniMax\",\n \"mini_model\": \"MiniMax-Text-01\",\n \"env_api_key\": \"MINIMAX_API_KEY\",\n \"base_url\": \"https://api.minimax.chat/v1/chat/completions\",\n \"doc\": \"docs/providers/minimax.md\"\n },\n {\n \"id\": \"pangu\",\n \"company\": \"Huawei\",\n \"mini_model\": \"pangu-pro\",\n \"env_api_key\": \"PANGU_API_KEY\",\n \"base_url\": \"https://modelarts.cn-north-4.myhuaweicloud.com/v1/chat/completions\",\n \"doc\": \"docs/providers/pangu.md\"\n },\n {\n \"id\": \"grok\",\n \"company\": \"xAI\",\n \"mini_model\": \"grok-2-latest\",\n \"env_api_key\": \"GROK_API_KEY\",\n \"base_url\": \"https://api.x.ai/v1/chat/completions\",\n \"doc\": \"docs/providers/grok.md\"\n }\n ]\n}\n"}}}} |