Política de Uso

Introdução e Visão Geral

A API do NeuralSeek pode suportar uma ampla gama de aplicações, como chatbots, pesquisa e resposta a perguntas em sites. Embora esperemos que a API traga principalmente benefícios para clientes e usuários finais, ela também gera preocupações de segurança que são importantes de caracterizar e mitigar.

Propriedade de Dados, Retenção e Responsabilidade de Conteúdo

Todos os dados e respostas gerados pelo NeuralSeek são, por design, baseados no conteúdo e treinamento dos usuários. O NeuralSeek não reivindica nenhum interesse ou propriedade sobre qualquer entrada ou resposta gerada pelo usuário, e o conteúdo ou respostas geradas pelo usuário não serão utilizados para aprimorar o serviço geral do NeuralSeek.

Os usuários têm a capacidade de excluir dados selecionados ou todos os dados de sua conta do NeuralSeek a qualquer momento, via API ou pela interface do usuário.

O NeuralSeek manterá os dados do usuário por um período mínimo de 30 dias após o último “toque” nesses dados. Por exemplo, se uma intenção for correspondida pelo NeuralSeek respondendo a uma pergunta, ou por meio da conexão com o registro de ida e volta com uma plataforma de Agente Virtual, então a pergunta do usuário, as perguntas de treinamento geradas, a  resposta e as análises serão retidas por um mínimo de 30 dias a partir desse ponto, e continuarão sendo estendidos a cada toque adicional.

As respostas geradas, sua relevância para a pergunta do usuário e a conformidade com as prioridades da empresa são de responsabilidade exclusiva do usuário. Os usuários devem aproveitar os recursos de Curadoria e Análises do NeuralSeek para monitorar qualquer linha de questionamento que se desvie das respostas corporativas esperadas e ajustar o conteúdo no repositório de conhecimento, respostas editadas na guia de Curadoria, bem como nas configurações do NeuralSeek na guia de Configuração para ajustar as saídas.

Política de Conteúdo

Proibimos o uso da API NeuralSeek para gerar determinados tipos de conteúdo.

Proibimos que os usuários gerem conscientemente – ou permitam que outros gerem conscientemente – os seguintes tipos de conteúdo:

• Ódio: conteúdo que expressa, incita ou promove ódio com base na identidade.
• Assédio: conteúdo que tem a intenção de assediar, ameaçar ou intimidar um indivíduo.
• Violência: conteúdo que promove ou glorifica a violência, celebra o sofrimento ou humilhação de outros.
• Autolesão: conteúdo que promove, incentiva ou retrata atos de autolesão, como suicídio, cortes e distúrbios alimentares.
• Sexual: conteúdo destinado a despertar excitação sexual, como a descrição de atividade sexual, ou que promove serviços sexuais (excluindo educação sexual e bem-estar).
• Político: conteúdo que tenta influenciar o processo político ou ser usado para fins de campanha.
• Spam: conteúdo em massa não solicitado.
• Enganação: conteúdo que é falso ou enganoso, como tentativas de fraudar indivíduos ou espalhar desinformação.
• Malware: conteúdo que tenta gerar ransomware, keyloggers, vírus ou outros softwares destinados a causar algum nível de dano.

Mesmo quando o objetivo de uma aplicação é bom, os usuários ainda podem interagir com ela de maneiras que violam as políticas do NeuralSeek. Consideramos isso como uso indevido, e isso se enquadra em duas categorias:

Violações de conteúdo: um usuário final que viola nossa política de conteúdo ao usar o aplicativo, por exemplo:

• Usar um aplicativo de direitos autorais para gerar desinformação.
• Usar um aplicativo de chatbot genérico para participar de conversas eróticas.

 

Reutilização: um usuário final redirecionando a funcionalidade do aplicativo para um caso de uso diferente e não aprovado, por exemplo:

• Instruir um chatbot a se comportar como um redator para prestar serviços.
• Usar um sistema projetado para resumir notas para cometer plágio acadêmico.

 

Requisitos padrão:

1. Passe o contexto (user-id) em todas as solicitações.
2. Não permita postagens automatizadas em outros sites (incluindo mídias sociais).
3. Os usuários finais não têm permissão para acessar a API ou automatizar processos. Todas as entradas dos usuários finais devem ser feitas por meio de uma interface gráfica do usuário (GUI).
4. As solicitações têm limites de taxa. Nosso limite padrão é de 10 solicitações por segundo. Para limites mais altos, entre em contato com [email protected]
5. Capture o feedback do usuário e mantenha um humano no processo. Utilize a guia “Curate” do NeuralSeek para monitorar a tendência das entradas dos usuários. Se você identificar casos de manipulação do usuário ou uso não intencional, entre em contato conosco pelo [email protected] para que possamos ajudar a mitigar o problema.
6. Utilize os limiares mínimos e de aviso. Tenha extrema cautela e consideração antes de permitir que o NeuralSeek responda a perguntas de usuários externos com confiança “0”. Essas respostas têm a mesma chance de estar corretas ou completamente erradas, o que pode entrar em conflito com a sua marca.

 

Desafios de segurança para sistemas Machine Learning de high-bandwidth e de respostas abertas

Nossa orientação para a segurança de API é informada por considerações específicas para sistemas com componentes de aprendizado de máquina (ML) que podem ter interações abertas de banda elevada com pessoas (por exemplo, por meio de linguagem natural).

• Os componentes de ML têm robustez limitada. Componentes de aprendizado de máquina só podem ser esperados para fornecer resultados razoáveis quando recebem entradas semelhantes às presentes nos dados de treinamento. Mesmo que um sistema de aprendizado de máquina seja considerado seguro quando operado em condições semelhantes aos dados de treinamento, operadores humanos podem fornecer entradas não familiares que colocam o sistema em um estado inseguro, e muitas vezes não é óbvio para um operador quais entradas levarão ou não a comportamentos inseguros. Sistemas de aprendizado de máquina de natureza aberta, que interagem com operadores humanos no público em geral (por exemplo, em um aplicativo de perguntas e respostas), também são suscetíveis a entradas adversas de operadores mal-intencionados que tentam deliberadamente colocar o sistema em um estado indesejado. Como uma mitigação para isso, entre outras, os clientes devem avaliar manualmente as saídas do modelo para cada caso de uso considerado, com essas saídas sendo geradas ao longo de uma variedade de entradas representativas, bem como algumas entradas adversas.
• Componentes de ML são tendênciosos. Os componentes de ML refletem os valores e vieses presentes nos dados de treinamento, assim como os de seus desenvolvedores. Sistemas que utilizam componentes de ML, especialmente aqueles que interagem com pessoas de maneira aberta, podem perpetuar ou amplificar esses valores. Preocupações com a segurança surgem quando os valores incorporados nos sistemas de ML são prejudiciais a indivíduos, grupos de pessoas ou instituições importantes. Para componentes de ML, como a API, que são treinados em grandes quantidades de dados de treinamento carregados de valores coletados de fontes públicas, a escala dos dados de treinamento e os complexos fatores sociais tornam impossível a remoção completa de valores prejudiciais.
• Sistemas de natureza aberta possuem extensas áreas de superfície para riscos. Sistemas que têm interações de alta largura de banda com os usuários finais, como diálogo em linguagem natural ou perguntas e respostas, podem ser usados para virtualmente qualquer finalidade. Isso torna impossível enumerar e mitigar exaustivamente todos os riscos potenciais de segurança antecipadamente. Em vez disso, recomendamos uma abordagem focada em considerar amplas categorias e contextos de possíveis danos, detecção e resposta contínuas para incidentes prejudiciais, e integração contínua de novas medidas de mitigação à medida que as necessidades se tornam aparentes.
• A segurança é um alvo em movimento para os sistemas de aprendizado de máquina. As características de segurança dos sistemas de ML mudam toda vez que esses componentes são atualizados, por exemplo, caso sejam implementados com novos dados ou se novos componentes forem treinados do zero com arquiteturas inovadoras. Uma vez que a aprendizagem de máquina é uma área de pesquisa ativa e novos níveis de desempenho são rotineiramente desbloqueados à medida que a pesquisa avança, os designers de sistemas de ML devem antecipar atualizações frequentes nos componentes e fazer planos para realizar análises contínuas de segurança.

 

Danos a considerar na análise de riscos

Abaixo, fornecemos exemplos de danos potenciais (ou caminhos para danos) que podem surgir em sistemas que envolvem a API como componente. Esta lista não é exaustiva, e nem todas as categorias se aplicarão a todos os sistemas que utilizam a API: os casos de uso variam na medida em que são abertos e têm altas apostas. Ao identificar danos potenciais, os clientes devem considerar seus sistemas no contexto, incluir tanto aqueles que utilizam o sistema quanto aqueles sujeitos a ele, e examinar fontes de danos alocativos e representacionais.

• Fornecendo informações falsas. O sistema pode apresentar informações falsas aos usuários em questões que são críticas para a segurança ou saúde, por exemplo, fornecer uma resposta incorreta a um usuário que pergunta se está passando por uma emergência médica e se deve procurar cuidados. A produção intencional e disseminação de informações enganosas através da API é estritamente proibida.
• Perpetuando atitudes discriminatórias. O sistema pode persuadir os usuários a acreditar em coisas prejudiciais sobre grupos de pessoas, por exemplo, usando linguagem racista, sexista ou capacitista.
• Angústia individual. O sistema pode criar resultados que são angustiantes para um indivíduo, por exemplo, encorajando comportamentos autodestrutivos (como jogos de azar, abuso de substâncias ou autolesão) ou prejudicando sua autoestima.
• Incentivo à violência. O sistema pode persuadir os usuários a se envolverem em comportamento violento contra qualquer outra pessoa ou grupo.
• Lesão física, danos materiais ou danos ao meio ambiente. Em alguns casos de uso, por exemplo, se um sistema que utiliza a API estiver conectado a atuadores físicos com o potencial de causar danos, o sistema é crítico em termos de segurança, e falhas que causam danos físicos podem resultar de comportamentos não previstos na API.

 

A importância da robustez

“Robustez” aqui refere-se a um sistema funcionando de forma confiável conforme pretendido e esperado em um determinado contexto. Os clientes da API devem garantir que sua aplicação seja tão robusta quanto necessário para um uso seguro e devem assegurar que essa robustez seja mantida ao longo do tempo.

A robustez é desafiadora. Modelos de linguagem, como os incluídos na API, são úteis para uma variedade de propósitos, mas podem falhar de maneiras inesperadas devido, por exemplo, ao conhecimento limitado do mundo. Essas falhas podem ser visíveis, como a geração de texto irrelevante ou obviamente incorreto, ou invisíveis, como a falha em encontrar um resultado relevante ao usar a pesquisa alimentada pela API. Os riscos associados ao uso da API variarão substancialmente entre os casos de uso, embora algumas categorias gerais de falhas de robustez a considerar incluam: geração de texto irrelevante para o contexto (fornecer mais contexto reduzirá essa probabilidade); geração de texto impreciso devido a uma lacuna no conhecimento mundial da API; continuação de um contexto ofensivo; e classificação imprecisa de texto.

O contexto é muito importante. Os clientes devem ter em mente que as saídas da API dependem fortemente do contexto fornecido ao modelo. Fornecer contexto adicional ao modelo (como fornecer alguns exemplos de alta qualidade de comportamento desejado antes da nova entrada) pode facilitar a orientação das saídas do modelo nas direções desejadas.

Incentivar a supervisão humana. Mesmo com esforços substanciais para aumentar a robustez, é provável que ocorram algumas falhas. Portanto, os clientes da API devem incentivar os usuários finais a revisar cuidadosamente as saídas da API antes de tomar qualquer medida com base nelas (por exemplo, disseminar essas saídas).

Continue testando. Uma maneira pela qual a API pode não funcionar conforme pretendido, apesar do desempenho inicialmente promissor, é se a distribuição de entrada se modificar ao longo do tempo. Além disso, o NeuralSeek pode modificar e aprimorar os modelos e a arquitetura subjacentes ao longo do tempo, e os clientes devem garantir que tais versões continuem a ter um bom desempenho em um contexto específico.

 

A importância da justiça

“Equidade” aqui significa garantir que a API não tenha desempenho degradado para usuários com base em suas características demográficas, nem produza texto que seja preconceituoso contra certos grupos demográficos. Os clientes da API devem tomar medidas razoáveis para identificar e reduzir danos previsíveis associados a preconceitos demográficos na API.

A equidade em sistemas de ML é muito desafiadora. Devido à API ser treinada com dados humanos, nossos modelos apresentam várias tendências, incluindo, mas não se limitando a, tendências relacionadas a gênero, raça e religião. Por exemplo: a API é treinada principalmente em texto em inglês e é mais adequada para classificar, pesquisar, resumir ou gerar tal texto. A API, por padrão, terá um desempenho inferior em entradas que são diferentes da distribuição de dados na qual foi treinada, incluindo idiomas que não sejam o inglês, bem como dialetos específicos do inglês que não estão bem representados em nossos dados de treinamento. O NeuralSeek forneceu informações básicas sobre algumas tendências que encontramos, embora essa análise não seja abrangente; os clientes devem considerar questões de imparcialidade que podem ser especialmente relevantes no contexto de seu caso de uso, mesmo que não sejam discutidas em nossa análise inicial. Observa-se que o contexto é crucial aqui: fornecer à API contexto insuficiente para orientar suas gerações ou fornecer contexto relacionado a tópicos sensíveis aumentará a probabilidade de resultados ofensivos.

Caracterize os riscos de equidade antes da implementação. Os usuários devem considerar sua base de clientes e a variedade de entradas que serão utilizadas com a API, e devem avaliar o desempenho da API em uma ampla gama de entradas potenciais para identificar casos nos quais o desempenho da API possa diminuir.

Ferramentas de filtragem podem ajudar, mas não são a solução. O NeuralSeek possui filtragem incorporada para bloquear possíveis saídas sensíveis. Os clientes devem ter em mente que essas medidas não são uma solução para eliminar todas as saídas potencialmente ofensivas – saídas ofensivas usando outras palavras consideradas “seguras” ainda podem ser geradas, e saídas legítimas podem ser bloqueadas.