mirror of
https://github.com/simstudioai/sim.git
synced 2026-04-06 03:00:16 -04:00
* feat(rippling): expand Rippling integration from 16 to 86 tools * fix(rippling): add required constraints on name and data subBlocks for create operations * fix(rippling): add subblock ID migrations for removed legacy fields * fix(docs): add MANUAL-CONTENT markers to tailscale docs and regenerate * fix(rippling): add missing response fields to tool transforms Add fields found missing by validation agents: - list_companies: physical_address - list/get_supergroups: sub_group_type, read_only, parent, mutually_exclusive_key, cumulatively_exhaustive_default, include_terminated - list/get/create/update_custom_object: native_category_id, managed_package_install_id, owner_id - list/get/create/update_custom_app: icon, pages - list/get/create/update_custom_object_field: managed_package_install_id * fix(rippling): add missing block outputs and required data conditions - Add 17 missing collection output keys (titles, workLocations, supergroups, etc.) - Add delete/bulk/report output keys (deleted, results, report_id, etc.) - Mark data subBlock required for create_business_partner, create_custom_app, and create_custom_object_field (all have required params via data JSON spread) - Add optional: true to get_current_user work_email and company_id outputs * fix(rippling): add missing supergroup fields and fix validation issues - Add 5 missing supergroup fields (allow_non_employees, can_override_role_states, priority, is_invisible, ignore_prov_group_matching) to types, list, and get tools - Fix ok fallback from true to false in supergroup inclusion/exclusion member update tools - Fix truthy check to null check for description param in create_custom_object_field * fix(rippling): add missing custom page fields and structured custom setting responses - Add 5 missing CustomPage fields (components, actions, canvas_actions, variables, media) to types and all page tools - Replace opaque data blob with structured field mapping in create/update custom setting transforms - Fix secret_value type cast consistency in list_custom_settings * fix(rippling): add missing response fields, fix truthy checks, and improve UX - Add 9 missing Worker fields (location, gender, date_of_birth, race, ethnicity, citizenship, termination_details, custom_fields, country_fields) - Add 5 missing User fields (name, emails, phone_numbers, addresses, photos) - Add worker expandable field to GroupMember types and all 3 member list tools - Add 5 optional params to trigger_report_run (includeObjectIds, includeTotalRows, formatDateFields, formatCurrencyFields, outputType) - Fix truthy checks to null checks in create_department, create/update_work_location - Fix customObjectId subBlock label to say "API Name" instead of "ID" * update docs * fix(rippling): fix truthy checks, add missing fields, and regenerate docs - Replace all `if (params.x)` with `if (params.x != null)` across 30+ tool files to prevent empty string/false/zero suppression - Add expandable `parent` and `department_hierarchy` fields to department tools - Add expandable `parent` field to team tools - Add `company` expandable field to get_current_user - Add `addressType` param to create/update work location tools - Fix `secret_value` output type from 'json' to 'string' in list_custom_settings - Regenerate docs for all 86 tools from current definitions Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add all remaining spec fields and regenerate docs - Add 6 advanced params to create_custom_object_field: required, rqlDefinition, formulaAttrMetas, section, derivedFieldFormula, derivedAggregatedField - Add 6 advanced params to update_custom_object_field: required, rqlDefinition, formulaAttrMetas, section, derivedFieldFormula, nameFieldDetails - Add 4 record output fields to all custom object record tools: created_by, last_modified_by, owner_role, system_updated_at - Add cursor param to get_current_user - Add __meta response field to get_report_run - Regenerate docs for all 86 tools Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): align all tools with OpenAPI spec - Add __meta to 14 GET-by-ID tools (MetaResponse pattern) - Fix supergroup tools: add filter to list_supergroups, remove invalid cursor from 4 list endpoints, revert update members to PATCH with Operations body - Fix query_custom_object_records: use query/limit/cursor body params, return cursor instead of nextLink - Fix bulk_create: use rows_to_write per spec - Fix create/update record body wrappers with externalId support - Update types.ts param interfaces and block config mappings - Add limit param mapping with Number() conversion in block config - Regenerate docs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): address PR review comments — add dedicated subBlocks, fix data duplication, expand externalId condition - Add dedicated apiName, businessPartnerGroupId, workerId, dataType subBlocks so required params are no longer hidden behind opaque data JSON - Narrow `data: item` in custom object record tools to only include dynamic fields, avoiding duplication of enumerated fields - Expand externalId subBlock condition to include create/update custom object record operations Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): remove data JSON required for ops with dedicated subBlocks create_business_partner, create_custom_app, and create_custom_object_field now have dedicated subBlocks for their required params, so the data JSON field is supplementary (not required) for those operations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): use rest-destructuring for all custom object record data output The spec uses additionalProperties for custom fields at the top level, not a nested `data` sub-object. Use the same rest-destructuring pattern across all 6 custom object record tools so `data` only contains dynamic fields, not duplicates of enumerated standard fields. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): make update_custom_object_record data param optional in type Matches the tool's `required: false` — users may update only external_id without changing data. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add dedicated streetAddress subBlock for create_work_location streetAddress is required by the tool but had no dedicated subBlock — users had to include it in the data JSON. Now has its own required subBlock matching the pattern used by all other required params. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add allOrNothing subBlock for bulk operations The bulk create/update/delete tools accept an optional allOrNothing boolean param, but it had no subBlock and no way to be passed through the block UI. Added as an advanced-mode dropdown with boolean coercion. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): derive spreadOps from DATA_OPS to prevent divergence Replace the hardcoded spreadOps array with a derivation from the file-level DATA_OPS constant minus non-spread operations. This ensures new create/update operations added to DATA_OPS automatically get spread behavior without needing a second manual update. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * updated * fix(rippling): replace generic JSON outputs with specific fields per API spec - Extract file_url, expires_at, output_type from report run result blob - Rename bulk create/update outputs to createdRecords/updatedRecords - Fix list_custom_settings output key mismatch (settings → customSettings) - Make data optional for update_custom_object_record in block - Update block outputs to match new tool output fields Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix landing * restore FF * fix(rippling): add wandConfig, clean titles, and migrate legacy operation values - Remove "(JSON)" suffix from all subBlock titles - Add wandConfig with AI prompts for filter, expand, orderBy, query, data, records, and dataType fields - Add OPERATION_VALUE_MIGRATIONS to migrate old operation values (list_employees → list_workers, etc.) preventing runtime errors on saved workflows Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): fix grammar typos and revert unnecessary migration - Fix "a object" → "an object" in update/delete object category descriptions - Revert OPERATION_VALUE_MIGRATIONS (unnecessary for low-usage integration) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * feat(landing): add interactive workspace preview tabs Adds Tables, Files, Knowledge Base, Logs, and Scheduled Tasks preview components to the landing hero, with sidebar nav items that switch to each view. * test updates * refactor(landing): clean up code quality issues in preview components - Replace widthMultiplier with explicit width on PreviewColumn - Replace key={i} with key={Icon.name} in connectorIcons - Scope --c-active CSS variable to sidebar container, eliminating hardcoded #363636 duplication - Replace '- - -' fallback with em dash - Type onSelectNav as (id: SidebarView) removing the unsafe cast * fix(landing): use stable index key in connectorIcons to avoid minification breakage --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
208 lines
9.0 KiB
Plaintext
208 lines
9.0 KiB
Plaintext
---
|
|
title: Guardrails
|
|
---
|
|
|
|
import { Callout } from 'fumadocs-ui/components/callout'
|
|
import { Image } from '@/components/ui/image'
|
|
import { Video } from '@/components/ui/video'
|
|
|
|
El bloque Guardrails valida y protege tus flujos de trabajo de IA comprobando el contenido contra múltiples tipos de validación. Asegura la calidad de los datos, previene alucinaciones, detecta información personal identificable (PII) y aplica requisitos de formato antes de que el contenido avance por tu flujo de trabajo.
|
|
|
|
<div className="flex justify-center">
|
|
<Image
|
|
src="/static/blocks/guardrails.png"
|
|
alt="Bloque de barandillas de protección"
|
|
width={500}
|
|
height={400}
|
|
className="my-6"
|
|
/>
|
|
</div>
|
|
|
|
## Tipos de validación
|
|
|
|
### Validación JSON
|
|
|
|
Valida que el contenido esté correctamente formateado en JSON. Perfecto para garantizar que las salidas estructuradas de LLM puedan analizarse de forma segura.
|
|
|
|
**Casos de uso:**
|
|
- Validar respuestas JSON de bloques de Agente antes de analizarlas
|
|
- Asegurar que las cargas útiles de API estén correctamente formateadas
|
|
- Verificar la integridad de datos estructurados
|
|
|
|
**Salida:**
|
|
- `passed`: `true` si es JSON válido, `false` en caso contrario
|
|
- `error`: Mensaje de error si la validación falla (p. ej., "JSON no válido: Token inesperado...")
|
|
|
|
### Validación con expresiones regulares
|
|
|
|
Comprueba si el contenido coincide con un patrón de expresión regular especificado.
|
|
|
|
**Casos de uso:**
|
|
- Validar direcciones de correo electrónico
|
|
- Comprobar formatos de números de teléfono
|
|
- Verificar URLs o identificadores personalizados
|
|
- Aplicar patrones de texto específicos
|
|
|
|
**Configuración:**
|
|
- **Patrón Regex**: La expresión regular para comparar (p. ej., `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$` para correos electrónicos)
|
|
|
|
**Salida:**
|
|
- `passed`: `true` si el contenido coincide con el patrón, `false` en caso contrario
|
|
- `error`: Mensaje de error si la validación falla
|
|
|
|
### Detección de alucinaciones
|
|
|
|
Utiliza Generación Aumentada por Recuperación (RAG) con puntuación LLM para detectar cuando el contenido generado por IA contradice o no está fundamentado en tu base de conocimientos.
|
|
|
|
**Cómo funciona:**
|
|
1. Consulta tu base de conocimientos para obtener contexto relevante
|
|
2. Envía tanto la salida de IA como el contexto recuperado a un LLM
|
|
3. El LLM asigna una puntuación de confianza (escala 0-10)
|
|
- **0** = Alucinación completa (totalmente infundada)
|
|
- **10** = Completamente fundamentado (totalmente respaldado por la base de conocimientos)
|
|
4. La validación se aprueba si la puntuación ≥ umbral (predeterminado: 3)
|
|
|
|
**Configuración:**
|
|
- **Base de conocimiento**: Selecciona entre tus bases de conocimiento existentes
|
|
- **Modelo**: Elige el LLM para la puntuación (requiere razonamiento sólido - se recomienda GPT-4o, Claude 3.7 Sonnet)
|
|
- **Clave API**: Autenticación para el proveedor LLM seleccionado (se oculta automáticamente para modelos alojados/Ollama o compatibles con VLLM)
|
|
- **Umbral de confianza**: Puntuación mínima para aprobar (0-10, predeterminado: 3)
|
|
- **Top K** (Avanzado): Número de fragmentos de la base de conocimiento a recuperar (predeterminado: 10)
|
|
|
|
**Salida:**
|
|
- `passed`: `true` si la puntuación de confianza ≥ umbral
|
|
- `score`: Puntuación de confianza (0-10)
|
|
- `reasoning`: Explicación del LLM para la puntuación
|
|
- `error`: Mensaje de error si la validación falla
|
|
|
|
**Casos de uso:**
|
|
- Validar respuestas del agente contra documentación
|
|
- Asegurar que las respuestas de atención al cliente sean precisas
|
|
- Verificar que el contenido generado coincida con el material de origen
|
|
- Control de calidad para aplicaciones RAG
|
|
|
|
### Detección de PII
|
|
|
|
Detecta información de identificación personal utilizando Microsoft Presidio. Compatible con más de 40 tipos de entidades en múltiples países e idiomas.
|
|
|
|
<div className="flex justify-center">
|
|
<Image
|
|
src="/static/blocks/guardrails-2.png"
|
|
alt="Configuración de detección de PII"
|
|
width={700}
|
|
height={450}
|
|
className="my-6"
|
|
/>
|
|
</div>
|
|
|
|
**Cómo funciona:**
|
|
1. Pasa el contenido a validar (p. ej., `<agent1.content>`)
|
|
2. Selecciona los tipos de PII a detectar usando el selector modal
|
|
3. Elige el modo de detección (Detectar o Enmascarar)
|
|
4. El contenido es escaneado para encontrar entidades PII coincidentes
|
|
5. Devuelve los resultados de detección y opcionalmente el texto enmascarado
|
|
|
|
<div className="mx-auto w-3/5 overflow-hidden rounded-lg">
|
|
<Video src="guardrails.mp4" width={500} height={350} />
|
|
</div>
|
|
|
|
**Configuración:**
|
|
- **Tipos de PII a detectar**: Selecciona de categorías agrupadas mediante selector modal
|
|
- **Común**: Nombre de persona, correo electrónico, teléfono, tarjeta de crédito, dirección IP, etc.
|
|
- **EE.UU.**: SSN, licencia de conducir, pasaporte, etc.
|
|
- **Reino Unido**: Número NHS, número de seguro nacional
|
|
- **España**: NIF, NIE, CIF
|
|
- **Italia**: Código fiscal, licencia de conducir, código IVA
|
|
- **Polonia**: PESEL, NIP, REGON
|
|
- **Singapur**: NRIC/FIN, UEN
|
|
- **Australia**: ABN, ACN, TFN, Medicare
|
|
- **India**: Aadhaar, PAN, pasaporte, número de votante
|
|
- **Modo**:
|
|
- **Detectar**: Solo identificar PII (predeterminado)
|
|
- **Enmascarar**: Reemplazar PII detectada con valores enmascarados
|
|
- **Idioma**: Idioma de detección (predeterminado: inglés)
|
|
|
|
**Salida:**
|
|
- `passed`: `false` si se detectan los tipos de PII seleccionados
|
|
- `detectedEntities`: Array de PII detectada con tipo, ubicación y confianza
|
|
- `maskedText`: Contenido con PII enmascarada (solo si modo = "Mask")
|
|
- `error`: Mensaje de error si la validación falla
|
|
|
|
**Casos de uso:**
|
|
- Bloquear contenido que contiene información personal sensible
|
|
- Enmascarar PII antes de registrar o almacenar datos
|
|
- Cumplimiento de GDPR y otras regulaciones de privacidad
|
|
- Sanear entradas de usuario antes del procesamiento
|
|
|
|
## Configuración
|
|
|
|
### Contenido a validar
|
|
|
|
El contenido de entrada para validar. Esto típicamente proviene de:
|
|
- Salidas de bloques de agente: `<agent.content>`
|
|
- Resultados de bloques de función: `<function.output>`
|
|
- Respuestas de API: `<api.output>`
|
|
- Cualquier otra salida de bloque
|
|
|
|
### Tipo de validación
|
|
|
|
Elige entre cuatro tipos de validación:
|
|
- **JSON válido**: Comprueba si el contenido es JSON correctamente formateado
|
|
- **Coincidencia regex**: Verifica si el contenido coincide con un patrón regex
|
|
- **Verificación de alucinaciones**: Valida contra base de conocimiento con puntuación de LLM
|
|
- **Detección de PII**: Detecta y opcionalmente enmascara información de identificación personal
|
|
|
|
## Salidas
|
|
|
|
Todos los tipos de validación devuelven:
|
|
|
|
- **`<guardrails.passed>`**: Booleano que indica si la validación pasó
|
|
- **`<guardrails.validationType>`**: El tipo de validación realizada
|
|
- **`<guardrails.input>`**: La entrada original que fue validada
|
|
- **`<guardrails.error>`**: Mensaje de error si la validación falló (opcional)
|
|
|
|
Salidas adicionales por tipo:
|
|
|
|
**Verificación de alucinaciones:**
|
|
- **`<guardrails.score>`**: Puntuación de confianza (0-10)
|
|
- **`<guardrails.reasoning>`**: Explicación del LLM
|
|
|
|
**Detección de PII:**
|
|
- **`<guardrails.detectedEntities>`**: Array de entidades PII detectadas
|
|
- **`<guardrails.maskedText>`**: Contenido con PII enmascarado (si el modo = "Mask")
|
|
|
|
## Ejemplos de casos de uso
|
|
|
|
**Validar JSON antes de analizar** - Asegurar que la salida del Agente es JSON válido
|
|
|
|
```
|
|
Agent (Generate) → Guardrails (Validate) → Condition (Check passed) → Function (Parse)
|
|
```
|
|
|
|
**Prevenir alucinaciones** - Validar respuestas de atención al cliente contra base de conocimiento
|
|
|
|
```
|
|
Agent (Response) → Guardrails (Check KB) → Condition (Score ≥ 3) → Send or Flag
|
|
```
|
|
|
|
**Bloquear PII en entradas de usuario** - Sanear contenido enviado por usuarios
|
|
|
|
```
|
|
Input → Guardrails (Detect PII) → Condition (No PII) → Process or Reject
|
|
```
|
|
|
|
## Mejores prácticas
|
|
|
|
- **Encadenar con bloques de Condición**: Usar `<guardrails.passed>` para ramificar la lógica del flujo de trabajo basada en resultados de validación
|
|
- **Usar validación JSON antes de analizar**: Siempre validar la estructura JSON antes de intentar analizar salidas de LLM
|
|
- **Elegir tipos de PII apropiados**: Seleccionar solo los tipos de entidades PII relevantes para tu caso de uso para mejor rendimiento
|
|
- **Establecer umbrales de confianza razonables**: Para detección de alucinaciones, ajustar el umbral según tus requisitos de precisión (más alto = más estricto)
|
|
- **Usar modelos potentes para detección de alucinaciones**: GPT-4o o Claude 3.7 Sonnet proporcionan puntuaciones de confianza más precisas
|
|
- **Enmascarar PII para registro**: Usar modo "Mask" cuando necesites registrar o almacenar contenido que pueda contener PII
|
|
- **Probar patrones regex**: Validar tus patrones regex exhaustivamente antes de implementarlos en producción
|
|
- **Monitorear fallos de validación**: Seguir los mensajes `<guardrails.error>` para identificar problemas comunes de validación
|
|
|
|
<Callout type="info">
|
|
La validación de barandillas ocurre de forma sincrónica en tu flujo de trabajo. Para la detección de alucinaciones, elige modelos más rápidos (como GPT-4o-mini) si la latencia es crítica.
|
|
</Callout>
|