Como Manter uma Base de Conhecimento de IA de Voz Atualizada Quando Sua Fonte da Verdade Está no SharePoint, no Azure ou em Documentos Privados
Sim, e a arquitetura é simples uma vez que você para de tentar fazer o Copilot Studio fazer isso. Você espelha os documentos autoritativos do SharePoint, do OneDrive ou do Azure Blob em um índice vetorial que o agente possui, e então deixa os webhooks do Microsoft Graph e as notificações do Event Grid conduzirem as atualizações incrementais. As edições na origem se propagam para o agente em poucos minutos. Sem reenvios.
A maioria das equipes esbarra nesse problema depois de já ter tentado os caminhos óbvios. O conector do SharePoint do Copilot Studio ainda não se atualiza automaticamente quando os arquivos mudam, uma limitação que a Microsoft confirmou em julho de 2025 e que não foi corrigida até o momento da escrita. O Azure AI Search consegue alcançar o SharePoint por meio de um indexador, mas o indexador não pode ficar por trás do Conditional Access, tem apenas suporte básico a ACL em preview e exige que você construa a camada do agente por conta própria. O padrão que este guia descreve usa a Retell AI como a camada de voz porque a sua API de base de conhecimento aceita pushes autenticados do seu próprio worker de sincronização, o que contorna todas as limitações que o caminho nativo da Microsoft impõe.
Um agente de voz que responde a partir de um espelho curado do seu corpus privado, com as edições se propagando de ponta a ponta em cinco a quinze minutos e uma passagem de reconciliação diária que captura qualquer coisa que o fluxo de eventos perca.
Ao final, a sua stack vai:
Antes de começar, você vai precisar de:
Sites.Selected é o preferido, Sites.Read.All é a alternativa mais ampla)Porque as ferramentas foram projetadas para um trabalho diferente. O Copilot Studio foi feito para resumir conteúdo para um humano lendo uma tela, não para alimentar um agente de voz que tem menos de um segundo para compor uma resposta falada. O indexador de SharePoint do Azure AI Search foi feito para busca empresarial, onde uma janela de atualização de quatro a seis horas é aceitável. Nenhum dos produtos foi projetado em torno da suposição de que uma política de cobrança editada às 9h precisa ser a resposta que quem liga ouve às 9h08.
Três restrições separam a voz do texto. A primeira é o orçamento de latência. Uma chamada de recuperação tem que retornar em menos de 100 milissegundos durante uma conversa ao vivo, então o índice tem que estar na mesma rede que o agente, e os blocos têm que ser pequenos o suficiente para serem embutidos inline sem estourar a janela de contexto do LLM. A segunda é a tolerância a falhas. Quando um chatbot retorna o link errado, o usuário clica de novo. Quando um agente de voz cita uma política aposentada em uma chamada de conformidade gravada, você tem um problema com logs de auditoria anexados a ele. A terceira é a expectativa de atualidade. As equipes de vendas ajustam os preços às terças. As equipes de suporte lançam atualizações de política após uma revisão de incidente na sexta. O agente que cita o número da semana passada é pior do que nenhum agente.
É por isso que a arquitetura separa a fonte da verdade da camada de recuperação. O SharePoint permanece canônico. O índice vetorial é um artefato derivado que o pipeline de sincronização mantém atual. Os modos de falha se tornam observáveis em vez de silenciosos.
Escolha por onde o documento é criado, não por onde é mais fácil de conectar. Cada origem sinaliza algo diferente sobre como o conteúdo é mantido.
As bibliotecas de documentos do SharePoint são a origem primária certa quando a propriedade é colaborativa e o conteúdo evolui por meio de revisão em comitê. Catálogos de serviços, manuais de política, wikis internos e playbooks de vendas tendem a viver aqui, com histórico de versões, comentários e fluxos de aprovação anexados. O custo é o excesso de metadados: um site típico contém quatro versões da mesma política, dois rascunhos aposentados e a pasta de capturas de tela de alguém.
O OneDrive raramente é a origem primária certa para um agente de voz. O conteúdo atrelado à conta de uma pessoa sai pela porta quando essa pessoa vai embora. Use o OneDrive apenas como uma área de preparação onde colaboradores individuais criam rascunhos que são promovidos a uma biblioteca do SharePoint após a revisão.
Os contêineres do Azure Blob são a origem certa quando os documentos são produzidos por sistemas upstream. PDFs gerados por um pipeline de cobrança, contratos despejados por uma ferramenta de CLM, extratos de um job de exportação e transcrições de um sistema de gravação, todos pertencem ao Blob. O volume é maior, a atualidade é mais difícil de forjar, e a nomenclatura dos arquivos segue qualquer convenção que o sistema produtor imponha, o que torna o espelhar-e-sincronizar mais simples do que a estrutura de forma livre do SharePoint.
A maioria das equipes corporativas sincroniza ambos. O SharePoint alimenta o lado de política e produto, o Blob alimenta o lado operacional e gerado por máquina, e a base de conhecimento do agente de voz funde os dois por trás de uma única API de recuperação.
Registre uma aplicação no Microsoft Entra ID, solicite permissões de aplicação e peça a um administrador de tenant para conceder o consentimento.
As permissões de aplicação rodam sob um service principal. O worker continua rodando durante a noite sem um usuário logado, e o token é consistente entre as chamadas. As permissões delegadas, por outro lado, atrelam o acesso a uma conta de usuário real e forçam uma reautenticação a cada 75 minutos aproximadamente, conforme as bibliotecas de segurança que a Microsoft usa agora. As permissões delegadas também não conseguem preservar as ACLs em nível de documento, como observa a própria documentação do indexador de SharePoint da Microsoft, o que se torna um problema no momento em que a conformidade pergunta quem pode ouvir o quê.
O escopo é onde a maioria das equipes compartilha demais. Conceder Sites.Read.All permite que o app leia todos os sites do tenant. É rápido na configuração e indefensável em uma auditoria. A alternativa mais restrita é Sites.Selected, em que um administrador de tenant pré-autoriza o app apenas contra IDs de site específicos. O worker vê as bibliotecas de que o agente precisa e nada mais. Use Sites.Selected desde o primeiro dia. Aplicar o escopo em nível de site depois do fato exige um novo consentimento e geralmente uma revisão de segurança que você não orçou.
Para o Azure Blob, atribua ao mesmo service principal a função Storage Blob Data Reader no contêiner específico. O escopo em nível de contêiner vence o escopo em nível de conta pelo mesmo motivo.
Combine duas primitivas do Microsoft Graph. Os webhooks dizem quando algo aconteceu. As consultas de delta dizem exatamente o que mudou.
Uma assinatura de webhook é um POST para /subscriptions com um caminho de recurso apontando para o drive (por exemplo, /sites/{site-id}/drive/root), um changeType de updated e um notificationUrl voltado para o endpoint HTTPS do seu worker. O corpo da notificação é intencionalmente enxuto. Ele carrega o ID do recurso e o tipo de mudança, nada mais. Isso é proposital. O worker usa a notificação como um sinal para chamar o endpoint de delta, onde o payload real vive.
A consulta de delta é /sites/{site-id}/drive/root/delta. Na primeira execução, sem token, você obtém uma enumeração completa mais um @odata.deltaLink opaco. Persista esse link literalmente. A cada execução subsequente, reexecute-o e o Graph retorna apenas os itens adicionados, modificados, renomeados ou excluídos desde a última chamada. A orientação de varredura da Microsoft é explícita: webhooks mais delta é o padrão recomendado para bibliotecas grandes, porque o polling puro vai te levar a ser throttled, e os webhooks puros vão perder dados se o endpoint estiver lento.
Dois pedaços de folclore que vale conhecer. O mesmo item pode aparecer mais de uma vez em uma página de delta, por design, porque o Graph expande as hierarquias de pastas e funde as mudanças concorrentes. Quando duplicatas aparecem, pegue a última ocorrência. As assinaturas também expiram. Renove em 75% do tempo de vida máximo, não no prazo final. Um job de renovação que falha silenciosamente é a razão mais comum para uma sincronização que antes funcionava começar a derivar para conteúdo desatualizado, e você descobre isso quando um cliente reclama.
Use o Event Grid para notificações em tempo real e o change feed para a reconciliação em lote. Eles resolvem problemas diferentes e a resposta de produção é rodar ambos.
O Event Grid envia eventos no momento em que um blob é criado, substituído ou excluído. Assine na conta de armazenamento, filtre por eventType para Microsoft.Storage.BlobCreated e Microsoft.Storage.BlobDeleted e roteie para o seu worker. Para o Azure Data Lake Storage Gen2, adicione um filtro na chamada de API FlushWithClose. Isso garante que o evento só dispare depois que o blob estiver totalmente confirmado. Pule isso e você vai processar uploads parciais, o que produz erros de ingestão que parecem corrupção de arquivo, mas não são.
O change feed é o log ordenado e durável por trás dos eventos. Conforme a documentação da Microsoft, ele fornece um log de transações garantido, persistido como arquivos Avro em $blobchangefeed/log/, escrito em poucos minutos após cada mudança. O Event Grid é de melhor esforço e pode descartar notificações sob carga. O change feed não pode. Rode um job diário que percorre o change feed e reconcilia contra o manifesto da sua base de conhecimento, e você terá uma rede de segurança por baixo do caminho em tempo real.
A combinação importa. O Event Grid sozinho é rápido, mas com perdas. O change feed sozinho é confiável, mas lento. Juntos, eles dão a você uma atualidade em escala de minutos no caminho feliz e consistência completa pela manhã no caminho infeliz.
O worker baixa o arquivo, normaliza-o e o envia para a API da plataforma. Três operações: criar, atualizar, excluir. O renomear se reduz a excluir-mais-criar.
A base de conhecimento da Retell AI aceita uma longa lista de formatos de documento, incluindo PDF, DOCX, PPTX, XLSX, CSV, TSV, TXT, MD, HTML, RTF, ODT, EPUB, além de formatos de mensagem e vários tipos de imagem. As restrições que vale conhecer: 50MB por arquivo, 25 arquivos por base e 1.000 linhas por 50 colunas para planilhas. O Markdown é ingerido da forma mais limpa quando você controla o formato de origem, e é por isso que as equipes muitas vezes rodam uma etapa de normalização que converte documentos do Word criados em Markdown antes do envio.
Quando a contagem de arquivos passa de 25, divida as bases por domínio em vez de por departamento. Um agente de cobrança vinculado a "billing-policies-en", "service-catalog-2026" e "exception-cases" recupera de forma limpa entre as três porque a similaridade de recuperação é computada por bloco, não por base. Dividir por departamento, por outro lado, cria os limites errados. A mesma pergunta de quem liga muitas vezes abrange dois departamentos, e o agente vai recuperar de apenas um deles.
Para o lado operacional, a idempotência é o que te salva quando a mesma notificação chega duas vezes. Faça o hash do conteúdo de cada arquivo e use o hash como o identificador do documento. Uma notificação duplicada para um arquivo inalterado produz um no-op em vez de uma entrada de índice duplicada.
Um extrator de texto puro vai perder silenciosamente 30 a 40 por cento do significado em um PowerPoint real ou em uma planilha financeira. O agente vai então citar com confiança os 60 por cento que sobreviveram, incluindo as partes que não fazem mais sentido sem a tabela de onde vieram.
Os PowerPoints codificam informações no layout do slide, nas células de tabela, em destaques baseados em imagem e nas notas do apresentador. O Excel codifica significado em cabeçalhos de coluna que abrangem células mescladas, em fórmulas que referenciam outras abas e na ordem das abas. A extração de texto ingênua retorna uma string plana de palavras com a estrutura removida. Dois caminhos sobrevivem em produção.
O primeiro é o parsing com reconhecimento de layout. Ferramentas como Unstructured, Azure Document Intelligence ou LlamaParse preservam as células de tabela e a estrutura do slide como Markdown. Elas são mais baratas por documento e previsíveis na saída. A desvantagem é que lidam bem com tabelas, mas mal com gráficos.
O segundo, que ganhou tração desde meados de 2025, é a extração baseada em imagem. Renderize cada slide ou planilha como uma imagem e passe-a por um LLM com capacidade de visão que retorna Markdown. A saída recupera tabelas, gráficos e destaques visuais que os extratores de texto perdem. O custo é maior por documento e mais lento, o que torna este o caminho certo para os documentos que realmente importam e o caminho errado para a ingestão em massa de tudo em um site do SharePoint.
A regra de decisão que se sustenta: roteie os documentos de política pelo caminho barato com reconhecimento de layout, roteie um pequeno conjunto de documentos visuais de alto valor (one-pagers, decks de slides que os executivos referenciam, as tabelas de tarifas que a sua equipe de vendas de fato usa) pelo caminho baseado em imagem. Não tente usar uma única abordagem para tudo.
Divisão recursiva de caracteres em 512 tokens com 10 a 20 por cento de sobreposição, três blocos recuperados na similaridade padrão. Ajuste a partir daí com base nos seus próprios dados de chamadas.
Esta não é a resposta popular. A resposta popular é a divisão semântica em blocos, que soa mais inteligente e tem um desempenho pior em benchmarks. O benchmark da Vecta publicado no início de 2026 colocou a divisão recursiva de 512 tokens em 69 por cento de precisão de recuperação e a divisão semântica em 54 por cento no mesmo corpus de 50 documentos. A pesquisa da NVIDIA chega ao mesmo lugar: consultas de fato (o tipo que um agente de voz recebe) têm o melhor desempenho em 256 a 512 tokens, com 10 a 20 por cento de sobreposição para preservar o contexto da frase entre os limites.
A implicação prática para a sincronização: mudar o tamanho do bloco ou o modelo de embedding invalida cada bloco existente na base. Se a recuperação de repente tiver um desempenho pior após uma passagem de ajuste, não remende de forma incremental. Apague a base, reingira a origem e aceite o custo de algumas horas de reprocessamento. A clareza que você ganha em cada resposta futura vale o refazer.
O ajuste do limiar de recuperação acontece depois que você tem dados de chamadas, não antes. Puxe 50 a 100 chamadas da análise pós-chamada, marque as falhas de bloco errado e ajuste ou a divisão em blocos da origem problemática ou o limiar de similaridade. A maioria das equipes ajusta demais no início. As configurações padrão estão corretas para 80 por cento dos casos de uso.
Construa um teste de loop fechado que rastreia da edição até a resposta falada com uma frase única e testável. Esta é a verificação de cinco minutos mais útil de todo o pipeline.
Escolha um documento e edite nele um valor numérico único. "Desconto do nível Premium: 12,5%" vira "Desconto do nível Premium: 14,0%". Salve no SharePoint. Em cinco a quinze minutos (notificação do Graph, processamento de delta, embedding), a mudança deve estar ativa no índice. Faça uma chamada de teste perguntando a questão. Se o agente disser 14,0%, o loop funciona.
Quando não funciona, a falha se isola de forma limpa. O worker recebeu o webhook? Verifique os logs do seu endpoint. A consulta de delta retornou o arquivo? Verifique os logs do worker. O upload foi bem-sucedido? Verifique a resposta da API. O bloco chegou à recuperação? Verifique o log de recuperação da chamada na análise de chamadas pós-chamada. Cada camada responde a uma pergunta de sim/não, e você encontra a camada quebrada em menos de dez minutos.
Rode este loop após cada mudança significativa no pipeline. Nova estratégia de divisão em blocos, novo modelo de embedding, nova origem, nova versão do worker de sincronização. Se o loop fecha, a mudança é segura para lançar. Se não, você tem uma reprodução precisa do bug.
Três camadas, aplicadas nesta ordem. Pode na origem. Restrinja no prompt. Observe na chamada.
Podar na origem é a camada que a maioria das equipes pula e paga por isso mais tarde. Quando uma política é aposentada, mova o arquivo para fora da pasta sincronizada. O padrão mais limpo é uma divisão de diretórios synced/ e archive/ dentro da mesma biblioteca do SharePoint, com o worker observando apenas o synced/. Duas versões indexadas da mesma política é uma receita para contradições confiantes, e você não consegue depurar para sair de documentos de origem conflitantes.
Restringir no prompt é a camada dois. Instrua o agente a responder apenas a partir do contexto recuperado da base de conhecimento e a escalar quando nenhum estiver disponível. Os benchmarks públicos mostram que o RAG ancorado corta as taxas de alucinação em 26 a 43 por cento em relação aos LLMs não ancorados. O ganho só se mantém quando a recuperação traz à tona o documento certo. Uma resposta de "nenhuma resposta encontrada, transferindo você" é quase sempre melhor do que uma errada com confiança, e uma regra de escalonamento que dispara em recuperações de baixa similaridade é uma das configurações de maior alavancagem no agente.
Observar na chamada é a camada três e onde o loop fecha. Marque cada erro com uma categoria: origem ausente, bloco errado recuperado, conteúdo desatualizado, má interpretação do modelo. Cada categoria tem uma correção diferente. As origens ausentes vão para a próxima passagem de ingestão. Os blocos errados geralmente significam que dois documentos discutem tópicos semelhantes com vocabulário diferente, o que se corrige com tags de metadados ou dividindo a origem. O conteúdo desatualizado remonta a uma falha de webhook que a reconciliação diária deveria ter capturado, e não capturou, o que é um bug no seu job de reconciliação.
Para uma equipe que lida com 5.000 chamadas por mês de três minutos cada, o uso da base de conhecimento é o menor item de linha por uma ordem de magnitude.
A Retell AI cobra US$ 0,07 por minuto pelo custo base da chamada, com o uso da base de conhecimento a US$ 0,005 por minuto por cima. Cada workspace inclui 10 bases de conhecimento gratuitas. Bases adicionais custam US$ 8 por mês. Para 15.000 minutos de tempo de chamada mensal, o uso da base de conhecimento acrescenta US$ 75. O custo base da chamada é de US$ 1.050. Compare ambos com o salário de SDR ou de recepção que o agente está compensando e a matemática se torna óbvia. O preço é consistente quer você use uma base ou sete, e não há taxa de plataforma por cima.
Os custos ocultos estão do lado da Microsoft, e geralmente são pequenos, mas fáceis de configurar errado. O Microsoft Graph cobra por chamada. O Azure Event Grid cobra por milhão de operações. Ambos são centavos em volumes típicos de sincronização. A forma de transformar isso em uma conta de verdade é fazer polling no SharePoint a cada 30 segundos em vez de assinar webhooks. Um bug assim já disparou os custos de consumo do Azure por um fator de cinquenta em pelo menos uma equipe que eu vi. Webhook mais delta mantém a conta estável, independentemente da frequência com que a origem muda.
Eles se repetem com frequência suficiente entre as implantações para merecerem um checklist.
Expiração da assinatura de webhook. As assinaturas não se renovam sozinhas. Adicione a expiração ao seu alerta e renove em 75 por cento do tempo de vida máximo. A expiração silenciosa é a causa de deriva mais comum.
Tratamento de exclusão. A maioria das equipes lança uma sincronização que lida com arquivos criados e atualizados e esquece os removidos. O agente então cita uma política que foi aposentada três meses atrás. Conecte o tipo de mudança deleted como um caso de primeira classe, não como um caso extremo.
Escopo de leitura de todo o tenant. Conceder Sites.Read.All na configuração é rápido. Seis meses depois, quando um auditor pergunta quais sites o service principal de voz pode ver, "todos eles" é a resposta errada. Use Sites.Selected desde o início.
Documentos acima do teto de 50MB. Manuais longos falham no upload silenciosamente quando excedem o limite por arquivo. Pré-processe documentos grandes demais dividindo em limites lógicos (capítulo, seção, linha de produto) e enviando cada parte como o seu próprio documento. Mantenha metadados pai-filho para que a recuperação possa costurá-los de volta se necessário.
Deriva entre as bases de conhecimento de staging e de produção. As equipes constroem um pipeline de sincronização contra uma base de staging, copiam a configuração do agente para a produção e esquecem que o agente de produção ainda aponta para os arquivos enviados manualmente do trimestre passado. Torne o ID da base de conhecimento explícito na sua configuração de implantação e verifique-o após cada release.
Sim. A arquitetura é autenticação por service principal via Microsoft Entra ID, arquivos puxados por um canal autenticado do Graph e uploads enviados para a API da base de conhecimento por HTTPS. Os documentos de origem permanecem no SharePoint com as suas ACLs existentes. A base de conhecimento mantém uma cópia indexada usada apenas para a recuperação durante as chamadas, e você pode limitar o escopo do service principal a um único site se a conformidade exigir.
Cinco a quinze minutos de ponta a ponta no caminho feliz. O detalhamento: entrega do webhook do Graph em poucos minutos, consulta de delta e download em menos de um minuto, parsing e embedding em um a três minutos dependendo do tamanho do documento. Uma vez indexada, a recuperação acrescenta menos de 100 milissegundos durante a própria chamada, então quem liga não percebe uma pausa.
Um job de reconciliação diário reexecuta a consulta de delta e compara os resultados com o manifesto da base de conhecimento, capturando qualquer coisa que o Event Grid ou o Graph tenha perdido. A combinação de webhooks em tempo real e uma varredura diária de delta é o padrão, recomendado na própria escrita de engenharia da Microsoft precisamente porque as notificações são de melhor esforço.
Sim. O mesmo padrão de worker se aplica ao Google Drive (via Drive Activity API), ao Amazon S3 (via S3 Event Notifications), ao Confluence, ao Notion e a qualquer origem que emita eventos de mudança. A API da base de conhecimento é agnóstica de origem. A única parte que muda é o código de autenticação e de escuta de eventos.
O conector do SharePoint do Copilot Studio não se atualiza automaticamente quando os arquivos mudam, uma limitação que a Microsoft confirmou em meados de 2025 e que não lançou uma correção até o momento da escrita. As soluções de contorno envolvem fluxos do Power Automate que disparam atualizações manuais. Além do problema de sincronização, o Copilot Studio é feito para superfícies de chat e não produz latência de voz abaixo de um segundo. Para agentes telefônicos, a arquitetura deste guia é o caminho.
A Retell AI vem com SOC 2 Type II, HIPAA com BAA em autoatendimento e GDPR, além de retenção de dados configurável e ocultação de PII. Para cargas de trabalho de saúde, o padrão é firmar o BAA antes que qualquer PHI toque o índice. A postura de conformidade em relação ao seu regime regulatório específico é sua para validar. As certificações em nível de infraestrutura cobrem a plataforma, não a sua política de classificação de conteúdo.
Sim. Um agente pode ter várias bases de conhecimento vinculadas, e cada base pode extrair de um pipeline de origem diferente. Um padrão comum é uma base por domínio lógico (cobrança, suporte, especificações de produto) com as origens claramente separadas. Os nós do fluxo de conversa também podem vincular uma base diferente a um nó específico quando os caminhos de vendas e suporte precisam de contexto distinto.
Um engenheiro que se sinta confortável com OAuth e webhooks para a camada de sincronização, um responsável de operações para a construção do agente e o ajuste de prompts, e um responsável de conteúdo que decide o que pertence à pasta sincronizada. A divisão que funciona na prática: a TI é dona do worker e da autenticação; as operações são donas do agente; a equipe de conteúdo é dona do que está no escopo. A arquitetura suporta uma configuração de uma só pessoa para prova de conceito e escala sem rearquitetura.
O indexador de SharePoint do Azure AI Search lida bem com a ingestão, mas tem limites rígidos que vale conhecer. Ele não suporta tenants com o Conditional Access habilitado. A preservação de ACL está em public preview, não em GA. A latência de atualização roda em horas, não em minutos. E você ainda precisa construir a camada do agente de voz por cima. Para busca empresarial pura, o AI Search é aceitável. Para voz, o padrão de sincronizar-para-a-Retell-AI é operacionalmente mais simples e mais rápido de implantar.
Divisão recursiva de 512 tokens com 10 a 20 por cento de sobreposição. Este é o padrão validado por benchmark nas avaliações de 2026 e supera a divisão semântica em cerca de 15 pontos em corpora de documentos reais. Três blocos recuperados na similaridade padrão. Ajuste apenas depois de ter 50 a 100 transcrições de chamadas reais para embasar a mudança.
O pipeline de sincronização é a metade sem glamour da IA de voz, e também é a metade que decide se a implantação é lançada ou trava. Um piloto que "funciona nos dados de demonstração" e desmorona no momento em que uma política muda é o modo de falha característico deste espaço, e a arquitetura acima é a correção.
Uma vez que a base de conhecimento está sólida, o mesmo agente se expande para fluxos de trabalho adjacentes nos mesmos dados. Suporte ao cliente com IA para perguntas recebidas, qualificação de leads para a saída, um recepcionista que roteia para qualquer um dos dois. O corpus que você curou para um se torna a fonte da verdade para todos eles.
Comece grátis com US$ 10 em crédito em retellai.com.
Veja quanto seu negócio poderia economizar ao migrar para agentes de voz com IA.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Um número de telefone de demonstração do consultório da Retell Clinic
Start building smarter conversations today.
.avif)
.avif)
