Construye con TypeSafe
TypeSafe hace que las unidades de inteligencia artificial sean utilizables como primitivas de programación: juicios pequeños que puedes componer en capacidades más grandes. Sus modelos System One devuelven juicios rápidos y enfocados que el software puede consumir directamente. Jev es el buque insignia de TypeSafe y el primer modelo System One. Entiende el lenguaje natural y devuelve respuestas y probabilidades tipificadas en lugar de generar texto o explicaciones de razonamiento. El código controla el flujo de trabajo; el modelo proporciona sentido común programable donde el código ordinario necesita comprensión semántica.
Lee la documentación en vivo
La documentación en vivo de TypeSafe es la fuente de verdad. Léela como parte de la tarea. Esta habilidad da dirección; los documentos contienen conceptos actuales, guías de indicaciones, contratos de API, uso del SDK, modelos, límites y ejemplos prácticos.
- Comienza con el índice de documentación para descubrir páginas y libros de cocina relevantes. Usa lecturas dirigidas en lugar de cargar todo el sitio.
- Mintlify sirve Markdown añadiendo
.mda la ruta de una página, por ejemplo cómo construir con TypeSafe. Sigue los enlaces del índice; convierte los enlaces de páginas de documentación sin extensión a.mdcuando sea útil. Resuelve los enlaces relativos contrahttps://docs.typesafe.ai. - Antes de escribir una integración, lee la página actual de la API o del SDK elegido y la guía de preguntas relevante para el diseño. Para un nuevo flujo de trabajo, inspecciona también el libro de cocina más cercano: a menudo muestra una mejor descomposición que un clasificador genérico.
- Si el índice no está disponible, usa los enlaces directos a continuación o la navegación del sitio. Si falla la recuperación de Markdown, prueba con la página normal. Si el acceso en vivo no está disponible, usa los documentos locales disponibles o los tipos del SDK instalado, indica esa limitación y evita inventar detalles dependientes de la versión.
| Tarea | Comienza aquí; sigue los detalles relevantes |
|---|---|
| Entender el modelo de programación | System One, guía de construcción |
| Explorar qué construir | Mapa de casos de uso, luego los libros de cocina relevantes del índice |
| Preparar entradas y preguntas | Estado, primitivas, luego la página de la primitiva elegida |
| Decidir cómo manejar la incertidumbre | Confianza |
| Escribir código de API | API HTTP, SDK de Python o SDK de JavaScript |
| Actualizar una integración antigua | Guía de migración y la referencia actual del SDK instalado |
Encuentra la forma útil
Empieza por el comportamiento que el usuario desea: qué mostrará, seleccionará, cambiará o delegará la aplicación. Trabaja hacia atrás hasta los juicios que necesita. Mantén las reglas conocidas, los cálculos, las búsquedas exactas y la ejecución en el código. Preserva la pila y el alcance elegidos por el usuario; añade TypeSafe donde la comprensión semántica ayude.
Al lluvia de ideas o elegir una arquitectura, considera más que la clasificación. Los patrones a continuación son puntos de partida: combina primitivas alrededor del objetivo del usuario, incluyendo ideas que no encajen en una receta establecida.
- Enrutar y rellenar argumentos conocidos. Una solicitud puede seleccionar un controlador y sus parámetros tipificados. Haz preguntas útiles específicas de la rama por adelantado y consume solo las respuestas relevantes. Explora llamada a funciones y fan-out especulativo.
- Seleccionar en lugar de generar. Encuentra valores candidatos o rangos de origen en el código, usa un juicio para seleccionar el deseado y luego cópialo o normalízalo. El código también puede ensamblar texto fuente en un documento formateado o guía de lectura. Explora extracción de valores y recuperación de estructura.
- Encontrar y juzgar evidencia. Recupera candidatos, compara su relevancia con una consulta y selecciona el contexto útil. Explora reranking y clasificación jerárquica.
- Convertir juicios en datos reutilizables. Puntúa dimensiones una vez, luego deja que el código o los controles del usuario cambien pesos, umbrales, clasificaciones y vistas. Con resultados etiquetados, esas señales pueden convertirse en características clásicas de ML. Explora puntuación compuesta y descubrimiento de características.
- Verificar y escalar. Revisa afirmaciones o campos específicos contra su evidencia; envía casos inciertos o fallidos a una persona o modelo de razonamiento. Explora verificaciones de citas y cascadas de extracción.
- Responder al estado cambiante. El código puede retener objetivos y observaciones mientras juicios frescos guían el siguiente paso acotado. Mantén el estado inferido distinto de los hechos observados y verifica la frescura antes de aplicar un resultado a una situación cambiada.
Para solicitudes abiertas, ofrece las pocas direcciones que mejor sirvan al objetivo del usuario y recomienda un punto de partida. Para una solicitud concreta, elige el patrón relevante y construye; una lluvia de ideas no es un desvío obligatorio.
Diseña los juicios
Elige según lo que significa la respuesta, luego lee la página de la primitiva relevante:
| Necesidad | Primitiva | Distinción importante |
|---|---|---|
| Uno de un conjunto definido | Choice | Elige una opción; su distribución compara opciones competidoras |
| Si una condición se cumple | Noul | Probabilidad de sí; sin confianza separada; usa uno por etiqueta cuando varias puedan aplicarse |
| Grado a lo largo de una dimensión descrita | Score | Posición ponderada por probabilidad en niveles ordenados; usa puntuaciones comparables por elemento para clasificación gradual |
Proporciona a cada pregunta suficiente estado relevante para responder: texto fuente, identidades, relaciones, políticas y hechos actuales. Prefiere campos JSON nombrados cuando el contexto tenga varias partes. Pon el juicio en instrucciones y define sus posibles respuestas en criterios. Los IDs de preguntas son para el código y no se envían al modelo; incluye el significado completo en la pregunta. Referencia el estado anidado con rutas entre comillas invertidas como ticket.messages[0].text.
Haz una pregunta estrecha y coherente por juicio. Divide dimensiones independientemente útiles, sin destruir la relación que se está juzgando. Una selección de acción acotada o interpretación contextual es válida; atómico no significa extracción literal de hechos o un límite de una oración. Las cadenas funcionan para preguntas simples. Usa objetos o arreglos estructurados cuando definiciones, contrastes, exclusiones o ejemplos aclaren instrucciones o criterios. Los niveles de Score deben describir situaciones concretas y valerse por sí mismos.
Mantén disponibles las respuestas necesarias. Incluye un resultado de no coincidencia cuando nada pueda encajar; usa un juicio de presencia separado cuando sea independientemente útil. Para la selección de valor de origen, verifica la cobertura de candidatos: el modelo no puede elegir un valor omitido.
Compón y verifica
Haz preguntas independientes sobre el mismo estado juntas, incluyendo preguntas especulativas útiles. Se ejecutan en paralelo y no pueden ver las respuestas de las demás. Indica cada premisa especulativa explícitamente; el código consume las respuestas aplicables. Una segunda solicitud está justificada cuando se necesita una respuesta anterior para obtener evidencia, construir nuevo estado o determinar las siguientes opciones. Las preguntas adicionales aún usan tokens; mide los presupuestos reales de solicitudes, el costo y la latencia de extremo a extremo.
Usa probabilidades y confianza para guiar el comportamiento, con umbrales evaluados en los datos del usuario y las consecuencias. La confianza de Choice/Score resume la concentración de la distribución, no la corrección general del flujo de trabajo ni el permiso para actuar. Un Noul cercano a 0.5 significa probabilidad similar para sí y no, no intensidad media. Varias alternativas aceptables también pueden distribuir la probabilidad; la baja confianza no necesita invalidar una elección de preferencia inofensiva. Ignora la incertidumbre en ramas no utilizadas.
Mantén la política explícita y los juicios brutos reutilizables. Las puntuaciones ponderadas se adaptan a preferencias compensatorias; una regla de "cualquier violación grave" necesita condiciones separadas. Cambiar un peso o filtro de visualización no necesita volver a ejecutar la inferencia cuando la evidencia y los significados de las preguntas no cambian. La salida tipificada garantiza la interfaz, no la verdad. Los modelos System One están entrenados para decisiones calibradas; valida su rendimiento en el dominio objetivo.
Prueba casos representativos y el comportamiento resultante de la aplicación. Para fallos, inspecciona el estado exacto, las preguntas, los candidatos, las respuestas, la composición y el resultado observado. Separa la evidencia faltante, los errores del modelo, los errores del código y las fallas del servicio. Trata los umbrales de los libros de cocina y los resultados de demostración como ejemplos a evaluar, no como reglas universales o limitaciones permanentes del modelo. Mantén las credenciales de API del lado del servidor en aplicaciones web.