Usted estĆ” aquĆ:
Capa Einstein Trust: DiseƱado para Trust
Einstein Trust Layer es un conjunto de funciones, procesos y polĆticas diseƱados para proteger la privacidad de los datos, mejorar la precisiĆ³n de la IA y promover el uso responsable de la IA en todo el ecosistema de Salesforce.
Ediciones necesarias
| Disponible en: Ediciones Enterprise, Performance y Unlimited con un complemento Einstein for Sales, Einstein for Platform, Einstein for Service, Einstein 1 Service o Einstein GPT Service. Para adquirir complementos, pĆ³ngase en contacto con su ejecutivo de cuentas de Salesforce. |
Para comprender cĆ³mo funciona la Capa Trust Einstein, echemos un vistazo a cĆ³mo fluyen los datos a travĆ©s de la Capa Trust y luego paseemos por cada parte de la trayectoria en detalle.
- Los datos en forma de una solicitud fluyen desde aplicaciones CRM, a travƩs de Einstein Trust Layer, al modelo de idioma grande (LLM), que denominaremos prompt journey.
- El LLM genera una respuesta utilizando la solicitud, que denominaremos generaciĆ³n de respuesta.
- A continuaciĆ³n, la respuesta generada fluye de vuelta a travĆ©s de la Capa Einstein Trust y de vuelta a las aplicaciones CRM, que denominaremos la trayectoria de respuesta.
ĀæCĆ³mo funciona?
Solicitar trayectoria
Para generar una respuesta desde el LLM, debe proporcionarle una solicitud. La solicitud puede proceder de cualquiera de las aplicaciones CRM. Puede crear una solicitud en Generador de solicitudes e invocarla desde Apex o un flujo.
Proteger la recuperaciĆ³n y fundamentaciĆ³n de datos
El primer paso en Trust Layer es la recuperaciĆ³n de datos segura. Para que el LLM genere una respuesta mĆ”s relevante y personalizada, requiere contexto adicional de sus datos de CRM. Este proceso de agregar contexto adicional a la solicitud es lo que denominamos fundamentaciĆ³n. Puede fundamentar sus solicitudes utilizando campos de combinaciĆ³n con datos de CRM, que pueden ser campos de registro, flujos, Apex, DMO de Data 360 y listas relacionadas.
La recuperaciĆ³n segura de datos significa que la solicitud se basa Ćŗnicamente en datos a los que el usuario que ejecuta tiene acceso.
El proceso de recuperaciĆ³n de datos respeta los permisos y controles de acceso existentes en Salesforce:
- La recuperaciĆ³n de datos para fundamentar la solicitud se basa en los permisos del usuario que ejecuta la solicitud.
- La recuperaciĆ³n de datos para fundamentar la solicitud mantiene todos los controles basados en funciones estĆ”ndar de Salesforce para permisos de usuario y seguridad a nivel de campo al fundamentar datos desde su instancia de CRM.
La fundamentaciĆ³n es dinĆ”mica ya que la fundamentaciĆ³n se produce en tiempo de ejecuciĆ³n y depende del acceso del usuario.
Enmascaramiento de datos para LLM
Las polĆticas de Einstein Trust Layer incluyen el enmascaramiento de datos, donde se detectan datos confidenciales y luego se enmascaran. Identificamos datos confidenciales utilizando dos mĆ©todos:
- Basado en patrĆ³n: Utilizamos patrones y contexto para identificar datos confidenciales en el texto de solicitud. EspecĆficamente, utilizamos patrones de expresiones regulares (regex) y palabras de contexto. TambiĆ©n utilizamos modelos de aprendizaje automĆ”tico entrenados para identificar datos que no tienen un patrĆ³n definido, como nombres de personas o empresas.
- Basado en campo: Utilizamos los metadatos en los campos que se clasifican utilizando Shield Platform Encryption o clasificaciĆ³n de datos para identificar campos confidenciales. Esto amplĆa la clasificaciĆ³n que ya aplicĆ³ a sus datos en su organizaciĆ³n al enmascaramiento de datos LLM.
Una vez identificados, los datos se enmascaran con un texto de marcador de posiciĆ³n para evitar que los datos se expongan a modelos externos. Capa Einstein Trust almacena temporalmente la relaciĆ³n entre las entidades originales y sus respectivos marcadores de posiciĆ³n. La relaciĆ³n se utiliza mĆ”s adelante para desenmascarar los datos en la respuesta generada.
Defensa de solicitud
Para ayudar a reducir la posibilidad de que el LLM genere algo no deseado o perjudicial, Generador de solicitudes y API de conexiĆ³n de plantilla de solicitud utilizan polĆticas del sistema. Las polĆticas del sistema son un conjunto de instrucciones al LLM sobre cĆ³mo comportarse de una manera determinada para generar Trust con los usuarios. Por ejemplo, podemos indicar al LLM que no dirija contenido o genere respuestas sobre las que no tenga informaciĆ³n. Las polĆticas del sistema son una forma de defenderse contra el jailbreak y solicitar ataques de inyecciĆ³n.
GeneraciĆ³n de respuestas
DespuĆ©s de que una solicitud estĆ© completamente hidratada y segura, estĆ” lista para enviarse a travĆ©s de la pasarela LLM. La pasarela rige las interacciones con diferentes proveedores de modelos y representa una forma unificada y segura de comunicarse con mĆŗltiples LLM. Los proveedores de pasarela y modelo utilizan el cifrado TLS para asegurarse de que los datos estĆ”n protegidos durante el trĆ”nsito.
Los modelos creados o ajustados por Salesforce estĆ”n alojados en el lĆmite de Salesforce Trust. Los modelos externos creados y mantenidos por proveedores externos, como OpenAI, estĆ”n en un lĆmite Trust compartido. Los modelos que crea y mantiene estĆ”n alojados en su infraestructura.
Tenemos una polĆtica de retenciĆ³n de datos cero vigente con proveedores de modelos de socios externos, como OpenAI o Azure OpenAI. La polĆtica establece que los datos enviados al LLM desde Salesforce no se conservan y se eliminan despuĆ©s de que se envĆe una respuesta de vuelta a Salesforce.
Capa Einstein Trust: La trayectoria de respuesta
Cuando se devuelve la respuesta generada desde el modelo de idioma grande, Einstein Trust Layer aplica ciertas polĆticas y procesos para asegurarse de que la respuesta es segura y Ćŗtil. Consulte Capa Einstein Trust: Trayectoria de respuesta.
