1. Tipologia das partes interessadas
Antes de começar a trabalhar na transparência da documentação do conjunto de dados e criar cards de dados, é importante identificar e convidar as partes interessadas de todo o ciclo de vida do conjunto de dados. Isso facilita a criação de cards de dados porque oferece tudo o que você precisa para fazer considerações mais consistentes ao criar conteúdo.
Para ajudar você a entender como as partes interessadas multifuncionais se envolvem no processo do ciclo de vida de um conjunto de dados, criamos uma tipologia que permite descobrir as proposições geralmente feitas sobre as partes interessadas individuais. Nossa tipologia é dividida em três grupos de partes interessadas envolvidos no ciclo de vida de um conjunto de dados: produtores, agentes e usuários.
Essa tipologia representa um contínuo de necessidades e expectativas em constante mudança dos conjuntos de dados e da documentação deles. Não existe uma solução única para todos os casos.
Produtores
Os produtores são criadores de conjuntos de dados e documentação, responsáveis pela coleta, propriedade, lançamento e manutenção de conjuntos de dados.
Basicamente, os produtores são responsáveis pela produção e publicação de conjuntos de dados, além do lançamento, da adoção e/ou do sucesso.
Os produtores também podem ser os indivíduos ou grupos recrutados para coletar ou rotular os dados e dar conselhos sobre métodos ou interpretação em vários pontos durante o ciclo de vida dos dados.
Dependendo do contexto, os produtores também podem representar seus membros da equipe, parceiros, clientes ou plataformas de hospedagem de dados atuais e futuros, todos responsáveis pela manutenção, implantação e monitoramento do conjunto de dados.
Agentes
Os agentes são partes interessadas que leem a documentação do conjunto de dados ou o cartão de dados e outras documentações relacionadas a modelos de machine learning (ML). Eles têm a capacidade de usar ou determinar como eles ou outras pessoas podem usar os conjuntos de dados ou sistemas de IA descritos.
Dependendo dos domínios, os agentes podem ter uma função operacional ou de revisor, como um pesquisador em um ambiente acadêmico que quer avaliar o uso adequado de um conjunto de dados ou um cientista de dados em uma equipe de produtos que quer determinar a adequação geral do conjunto de dados em relação à integração de produtos.
Essa distinção é importante porque os revisores incluem partes interessadas que talvez nunca usem o conjunto de dados diretamente, mas ainda interagem com o card de dados, como consultores do setor, jornalistas investigativos, representantes da comunidade e entidades legais. Os agentes podem ou não ter a experiência técnica para navegar pelas informações apresentadas na documentação típica de conjuntos de dados, mas geralmente têm acesso à experiência conforme necessário.
Usuários
Os usuários são pessoas e representantes que interagem com produtos que dependem de modelos treinados em conjuntos de dados.
Os usuários podem consentir em fornecer dados como parte da experiência do produto, mas geralmente exigem um conjunto significativamente diferente de explicações e controles fundamentados nas experiências do produto, mesmo quando se trata de conjuntos de dados.
Resumo
A tabela a seguir resume os grupos de partes interessadas por descrições, responsabilidades, exemplos e tarefas comuns:
Grupo de partes interessadas | Descrição | Responsabilidades | Exemplos | Tarefas comuns |
Produtores | Criar conjuntos de dados e/ou documentação. | Projetar, criar, testar a qualidade, documentar, lançar, adotar, manter e atualizar conjuntos de dados. | Pesquisadores, cientistas e analistas de dados, engenheiros de software e gerentes de produtos e programas | Adoção, divulgação, preparação para o futuro, justiça e segurança de conjuntos de dados, além de melhorias |
Agentes | Avaliar e usar o conjunto de dados para o trabalho, produtos, organizações ou comunidades. | Usar o card de dados, mas não interagir com o conjunto de dados em si. | Engenheiros de ML ou de produtos, pesquisadores, fornecedores terceirizados, especialistas no assunto, setor, consultores, especialistas em políticas, provedores de serviços de dados e liderança ou gestão | Gerenciar complexidade, ser responsável, fazer concessões, implantar na produção, arquivar |
Usuários | Interagir com os produtos, dispositivos e apps criados por agentes que usam os conjuntos de dados do produtor. | Podem contribuir com dados usando produtos e fornecer indicadores úteis para produtores e agentes. | Colaboradores de dados, usuários do produto e representantes de coortes de usuários | Usar produtos, entender dados e privacidade, dar feedback e levantar preocupações |
2. Mapear as partes interessadas
Agora que você já conhece nossa tipologia, pode analisar o ciclo de vida do conjunto de dados para identificar as partes interessadas com esta atividade básica de mapeamento. Ao longo da atividade, anote quem pode interagir com o conjunto de dados ou a documentação dele. Além disso, considere como as partes interessadas podem contribuir com os cards de dados.
Para mapear seus stakeholders, siga estas etapas:
- Liste os produtores que vão criar os cards de dados.
- Liste os agentes que vão ler e usar os cards de dados.
- Liste os usuários que vão usar ou ser afetados pelo conjunto de dados descrito no card de dados.
- Use o modelo a seguir para criar um mapa dos seus stakeholders, das funções deles na criação de cards de dados e da finalidade dos cards. Esse mapa dá uma ideia das necessidades downstream da documentação do conjunto de dados e permite atribuir prioridades e responsabilidades ao longo do processo.
3. Jornadas de informações do agente (AIJs)
Com as partes interessadas mapeadas, você pode determinar o que é essencial transmitir aos agentes (seus principais stakeholders) no card de dados para que eles tenham sucesso.
Normalmente, a experiência que uma pessoa tem ao interagir com a tecnologia é chamada de jornada do usuário. No entanto, estamos falando de um agente que precisa adquirir informações suficientes sobre um conjunto de dados para tomar uma decisão embasada. Por isso, chamamos essas experiências de jornada de informações do agente (AIJ).
O objetivo de uma AIJ é entender o seguinte:
- As tarefas para as quais os agentes podem querer um conjunto de dados.
- As informações que os agentes precisam para concluir as tarefas.
- O processo pelo qual os agentes deduzem informações.
As AIJs incluem o seguinte:
Exemplo
Por exemplo, suponha que um dos seus agentes seja um cientista de dados. Uma AIJ para um cientista de dados pode ser assim:
Como cientista de dados, quero saber a estrutura do conjunto de dados. Por isso, pergunto…
... qual é o formato dos dados?
... qual é a modalidade do conjunto de dados?
... quantos recursos há no conjunto de dados?
... quantos atributos são projetados?
... quais recursos têm uma correlação forte?
... se houver dependências na estrutura?
Aqui está outro exemplo para um agente que pode trabalhar na política de produtos e definir diretrizes relacionadas à produção e ao desenvolvimento de um produto:
Como um assistente de política, quero saber como os dados podem ser usados indevidamente. Por isso, pergunto...
... qual era o uso pretendido do conjunto de dados?
... qual aplicativo solicitou a criação do conjunto de dados?
... quais são as aplicações conhecidas perigosas ou arriscadas do conjunto de dados?
... qual é o risco para grupos específicos?
... como os usos pretendidos desse conjunto de dados afetam as partes interessadas?
... como pedir reparação?
4. Escrever seus AIJs
- Escreva algumas AIJs com base nos comandos a seguir:
- Perceba como você não apenas tem seus stakeholders em mente, mas também algumas perguntas iniciais que acha que eles gostariam de ter respondidas ao ler seu cartão de dados. Isso significa que você está mais perto do conjunto final de perguntas que devem ser incluídas no card de dados.
5. Óptica
Você deve ter notado o uso dos termos perspectiva, lente e escopo para enquadrar os AIJs. Embora esses termos tenham sido definidos anteriormente, eles fazem parte de uma metáfora orientadora chamada óptica. Criamos essas perguntas para ajudar você a pensar em como seus agentes podem entender seu conjunto de dados.
Escopos
Na óptica, os escopos usam lentes e espelhos para detectar, observar, ampliar, refletir e até testar materiais. No contexto de conjuntos de dados, essa é uma ótima metáfora porque você foca e formula perguntas para revelar aspectos óbvios, não óbvios, visíveis e invisíveis.
Chamamos isso de escopos, uma maneira de fazer uma série de perguntas em sucessão para entender os conjuntos de dados. Ao combinar escopos de diferentes granularidades, você pode criar conteúdo que ajuda seus agentes a estabelecer um entendimento coeso dos conjuntos de dados usando relatórios de transparência.
A tabela a seguir contém os três tipos de escopos no nosso framework, além de uma descrição, um exemplo e a finalidade de cada um:
Escopo | Descrição | Exemplo | Purpose |
Telescópico | Perguntas sobre atributos comuns em vários conjuntos de dados. Elas marcam características. | Este conjunto de dados contém informações de identificação pessoal (PII)? | Apresente e defina o contexto para mais informações que ajudam seus agentes a navegar no card de dados ou no artefato de transparência. |
Periscópico | Perguntas sobre atributos específicos do conjunto de dados do produtor. Elas descrevem observações. | Quantos recursos contêm PII? | Geralmente reservado para o fornecimento de informações operacionais, como a forma e o tamanho do conjunto de dados, ou informações funcionais, como fontes ou intenções. |
Microscópico | Perguntas sobre aspectos não observáveis dos conjuntos de dados, como decisões, processos e impactos. Elas exigem explicações. | Como as PII foram anonimizadas neste conjunto de dados? | Extraia explicações detalhadas de decisões ou resuma documentos de processos mais longos que regem as respostas às perguntas periscópicas e telescópicas correspondentes. |
É importante considerar esses três tipos de escopos durante todo o processo de criação da sua ficha de dados. Um card de dados com apenas telescópios descreve informações óbvias sobre seu conjunto de dados e não agrega valor. Um card de dados com apenas periscópios pode ficar muito técnico sem detalhes sobre contexto, relevância ou importância. Um card de dados com apenas microscópios pode fazer com que os agentes se percam facilmente nos detalhes e não consigam ter uma visão geral.
Por isso, as interpretações de um card de dados são muito influenciadas pela presença ou ausência desses níveis de escopos. Essas perguntas permitem que agentes e produtores avaliem o risco, planejem mitigações e, quando relevante, identifiquem oportunidades para melhorar a criação de conjuntos de dados. Juntos, telescópios, periscópios e microscópios fornecem detalhes úteis para que várias partes interessadas possam navegar pela página de detalhes sem se perder.
Exemplo
Na seção Jornadas de informações do agente (AIJs), você viu alguns exemplos de AIJs, incluindo um para um cientista de dados. Se você analisar esse exemplo com atenção, vai perceber que é possível agrupar algumas dessas perguntas por escopos, incluindo as seguintes:
Como cientista de dados, quero saber a estrutura do conjunto de dados. Por isso, pergunto…
Telescopic (link em inglês)
... qual é o formato dos dados?
... qual é a modalidade do conjunto de dados?
Periscopic (em inglês)
... quantos recursos há no conjunto de dados?
... quantos atributos são projetados?
Microscópico
... quais recursos têm uma correlação forte?
... se houver dependências na estrutura?
É muito provável que você já tenha criado algumas perguntas telescópicas, periscópicas e microscópicas pensando nos seus agentes.
6. Reestruturar seus AIJs com escopos
- Para reestruturar seus AIJs com escopos, use o seguinte comando de exemplo:
7. Parabéns
Parabéns! Você começou a criar um card de dados. Agora você já pode avaliar suas perguntas.