Melhores práticas para melhorar a geração de consultas a agentes de dados

Um agente de dados gera melhores consultas quando tem um contexto focado e preciso sobre os dados que pode usar. Nomes de objetos e metadados de esquemas fornecem um ponto de partida, mas podem não explicar o significado de negócio, os valores esperados, as relações ou a lógica de consulta necessária para responder a uma pergunta.

Use a configuração que melhor corresponde ao contexto que precisa de fornecer:

Para uma visão geral destas definições, consulte Configurações do agente de dados.

Use nomes claros de esquemas

Use nomes descritivos para fontes de dados, tabelas e colunas quando controlar o esquema. Nomes como CustomerOrders, , e product_unit_price dão ao agente sinais mais úteis do que nomes como Table1, date1, e valueorder_submission_date.

Não confies apenas no nome. Mesmo um nome técnico claro pode não comunicar o significado comercial do objeto, o nível de detalhe, as unidades ou os valores válidos. Use descrições e instruções de fontes de dados para fornecer esse contexto.

Limitar o esquema selecionado

Selecione apenas as tabelas, colunas, vistas e funções necessárias para as perguntas que o agente de dados deve responder. Objetos irrelevantes aumentam a ambiguidade e dão à ferramenta de geração de consultas mais caminhos possíveis a considerar.

Por exemplo, se os utilizadores perguntarem sobre as encomendas atuais de clientes, não incluam tabelas de preparação arquivadas ou tabelas financeiras não relacionadas. Quando dois objetos selecionados contêm dados semelhantes, explique qual deles é autoritativo e quando usar cada um.

Descrever objetos de esquema (Pré-visualização)

Para esquemas SQL grandes ou ambíguos, use descrições de objetos de esquema para explicar o que tabelas individuais, colunas e outros elementos de esquema representam. As descrições dos objetos do esquema só estão disponíveis quando o agente de dados utiliza o runtime de pré-visualização.

Descrições são úteis quando:

• Os nomes dos objetos são abreviados, genéricos ou semelhantes entre si.
• O grão ou a função comercial de uma mesa não é evidente pelo seu nome.
• Uma coluna contém códigos, flags, unidades ou valores de categoria que requerem interpretação.
• Uma coluna de data representa um evento empresarial específico, como o envio de uma encomenda em vez de o cumprimento.
• O esquema é demasiado grande para explicar todos os objetos claramente nas instruções da fonte de dados.

Descreva tanto o significado como os valores esperados quando essa informação afeta a geração de consultas. Por exemplo:

Prioriza descrições para objetos que sejam difíceis de inferir. Evite repetir um nome óbvio sem acrescentar contexto empresarial.

Utilizar instruções da origem de dados nas regras aplicáveis a vários objetos

As instruções da fonte de dados fornecem orientações para gerar consultas para uma fonte de dados específica. Use-os para contexto que abrange múltiplos objetos de esquema ou defina como uma consulta deve ser construída, incluindo:

• Tabelas autoritativas para um tema.
• Chaves de junção e caminhos de junção obrigatórios.
• Granularidade da tabela e regras de deduplicação.
• Filtros padrão, como usar apenas registos atuais ou ativos.
• Lógica de datas, calendários fiscais e pressupostos de fusos horários.
• Cálculos ou colunas de saída obrigatórios.

Escreva instruções diretas que indiquem o que o agente deve fazer. Por exemplo, use "Associar EmployeeStatusFact a EmployeeDim com base em EmployeeID" em vez de "Evite associar incorretamente tabelas de funcionários."

Mantenha as instruções focadas. Coloque definições específicas de objeto nas descrições dos objetos do esquema em vez de usar espaço limitado de instruções como glossário para cada tabela e coluna.

Definir termos de negócio e valores esperados

Defina terminologia que os utilizadores possam incluir nas suas perguntas, mas que não corresponde diretamente ao esquema. Exemplos incluem siglas como "MAU", significados específicos da organização para "cliente ativo" e distinções como ano fiscal versus ano civil.

Documente também os valores que o agente precisa para construir corretamente os filtros:

• Se uma coluna de estado usa "CA" ou "California".
• Se um valor booleano é armazenado como 1 e 0, Y e N, ou texto.
• Se os valores da moeda são armazenados em dólares ou cêntimos.
• Quais valores de estado representam registos concluídos, cancelados ou ativos.
• Se nulo, zero ou uma data sentinela têm um significado especial.

Coloque uma definição na descrição do objeto do esquema quando esta se aplica a um objeto. Coloque-o nas instruções da fonte de dados quando se aplica em toda a fonte de dados ou afeta a lógica de consulta multi-objeto.

Explique as relações e o grão da tabela

As junções precisas dependem de mais do que apenas nomes de colunas correspondentes. Identifique o grão das tabelas importantes, caminhos de relacionamento válidos e chaves que não sejam óbvias a partir dos metadados.

Por exemplo, explique se uma tabela de vendas contém uma linha por encomenda, linha de encomenda ou total diário de produto. Se a junção de duas tabelas de factos duplicar linhas, instrua o agente a agregar cada tabela antes da junção ou a utilizar a tabela de dimensões apropriada.

Inclua orientações sobre relacionamentos, tais como:

- Join `OrderItems` to `Orders` on `OrderID`.
- Join `Orders` to `Customers` on `CustomerID`.
- Aggregate `OrderItems` to one row per `OrderID` before joining to order-level payment totals.

Use exemplos de consultas para lógica complexa

Use consultas de exemplo quando mostrar que a consulta é mais clara do que ao descrever a lógica em prosa. Um bom exemplo emparelha uma pergunta representativa em linguagem natural com uma consulta válida que demonstra o padrão esperado.

Priorize exemplos que demonstrem:

• Junções entre várias tabelas ou pré-agregação obrigatória.
• Cálculos específicos do negócio.
• Datas relativas, períodos fiscais ou lógica de instantâneo.
• Filtros que mapeiam a terminologia do utilizador para valores armazenados.
• Classificação, funções de janela ou outros padrões de interrogação complexos.

Mantenha cada exemplo focado num padrão reutilizável. Evite exemplos sobrepostos ou contraditórios e verifique se todos os exemplos ainda correspondem ao esquema atual.

Testar e refinar o contexto

Teste perguntas de representantes, inspecione a consulta gerada e identifique que contexto estava em falta ou mal compreendido. Atualize a configuração mais próxima do problema:

• Remova objetos irrelevantes ou adicione os que faltam na seleção de esquemas.
• Esclareça o significado ou os valores esperados de um objeto na descrição do seu esquema.
• Adicionar lógica de negócio entre objetos ou de junção às instruções da fonte de dados.
• Adicione uma consulta de exemplo quando o agente precisar de aprender um padrão específico de consulta.

Repita este processo à medida que o esquema e as perguntas dos utilizadores evoluem. Para um fluxo de trabalho estruturado de testes, consulte Desenvolver um agente de dados utilizando um processo iterativo.

Próximos passos

• Configurações do agente de dados
• Adicionar descrições de objetos de esquema a um agente de dados
• Runtime do agente de dados Fabric
• Exemplos de consultas
• Adicionar e configurar fontes de dados