Depois de superar o hype do chatbot, fica claro que a IA generativa é uma ferramenta útil, fornecendo uma maneira de navegar em aplicativos e serviços usando linguagem natural. Ao vincular nossos grandes modelos de linguagem (LLMs) a fontes de dados específicas, podemos evitar os riscos que advêm do uso apenas de dados de treinamento.

Embora seja possível ajustar um LLM em dados específicos, isso pode ser caro e demorado, e também pode prendê-lo a um período de tempo específico. Se quiser respostas precisas e oportunas, você precisará usar a geração aumentada de recuperação (RAG) para trabalhar com seus dados.

RAG: o coração dos copilotos da Microsoft

As redes neurais que alimentam os LLMs são, no fundo, sofisticados mecanismos de busca vetorial que extrapolam os caminhos dos vetores semânticos em um espaço n-dimensional, onde quanto maior a dimensionalidade, mais complexo é o modelo. Portanto, se você for usar RAG, precisará ter uma representação vetorial de seus dados que possa criar prompts e propagar os vetores usados ​​para gerar a saída de um LLM. É por isso que é uma das técnicas que alimentam os vários Copilots da Microsoft.

Já falei sobre essas abordagens antes, observando o Prompt Flow do Azure AI Studio, a estrutura de agente inteligente da Microsoft, o Semantic Kernel, o impulso da Open AI da Power Platform em seu Q and A Maker Copilot Studio reprojetado e muito mais. Em todas essas abordagens, há uma ferramenta fundamental que você precisa levar para suas aplicações: um banco de dados vetorial. Isso permite que você use as ferramentas de incorporação usadas por um LLM para gerar vetores de texto para o seu conteúdo, acelerando a pesquisa e fornecendo as sementes necessárias para conduzir um fluxo de trabalho RAG. Ao mesmo tempo, o RAG e abordagens semelhantes garantem que os dados da sua empresa permaneçam nos seus servidores e não sejam expostos ao mundo mais amplo, além das consultas protegidas por meio de controles de acesso baseados em funções.

Embora a Microsoft tenha adicionado recursos de pesquisa de vetores e índice de vetores aos seus próprios bancos de dados, bem como suporte a armazenamentos de vetores de terceiros no Azure, uma tecnologia de banco de dados importante está faltando na história do RAG. Esses bancos de dados ausentes são bancos de dados gráficos, uma abordagem NoSQL que fornece um caminho fácil para uma representação vetorial de seus dados com a vantagem adicional de codificar relacionamentos nos vértices que ligam os nós gráficos que armazenam seus dados.

Adicionando gráficos ao Azure AI com Neo4j

Bancos de dados gráficos como esse não devem ser confundidos com o Microsoft Graph. Ele usa um modelo de nó para consultas, mas não o utiliza para inferir relacionamentos entre nós. Os bancos de dados gráficos são uma ferramenta mais complexa e, embora possam ser consultados usando GraphQL, possuem um processo de consulta muito mais complexo, usando ferramentas como o mecanismo de consulta Gremlin.

Um dos bancos de dados gráficos mais conhecidos é o Neo4j, que anunciou recentemente suporte para a versão empresarial de seu serviço hospedado em nuvem, Aura, no Azure. Disponível no Azure Marketplace, é uma versão SaaS da conhecida ferramenta local, permitindo que você comece a usar os dados sem perder tempo configurando sua instalação. Duas versões estão disponíveis, com diferentes opções de memória baseadas em capacidade reservada, para que você não precise se preocupar com a indisponibilidade de instâncias quando precisar delas. Não é barato, mas simplifica o trabalho com grandes quantidades de dados, economizando muito tempo ao trabalhar com data lakes de grande escala no Fabric.

Construindo gráficos de conhecimento a partir de seus dados

Uma característica importante do Neo4J é o conceito de gráfico de conhecimento, ligando informações não estruturadas em nós em um gráfico estruturado. Dessa forma, você pode ver rapidamente as relações entre, digamos, um manual do produto e toda a lista de materiais incluída no produto. Em vez de apontar uma única peça que precisa ser substituída para uma correção, você tem um gráfico de dependência completo que mostra o que isso afeta e o que é necessário para fazer a correção.

Uma ferramenta como o Neo4j, que pode ficar no topo de um data lake em grande escala, como o Fabric da Microsoft, oferece outra maneira útil de criar fontes de informações para um aplicativo RAG. Aqui, você pode usar a ferramenta de visualização gráfica que faz parte do Neo4j para explorar as complexidades de seus lagos, gerando os links subjacentes entre seus dados e fornecendo uma visão mais flexível e compreensível de seus dados.

Um aspecto importante de um gráfico de conhecimento é que você não precisa usar tudo. Você pode usar os relacionamentos gráficos para filtrar rapidamente informações desnecessárias para seu aplicativo. Isso reduz a complexidade e acelera as pesquisas. Ao garantir que os vetores e prompts resultantes estejam confinados a um conjunto estrito de relacionamentos, reduz os riscos de resultados errados do seu LLM.

Existe até a perspectiva de usar LLMs para ajudar a gerar esses gráficos de conhecimento. As ferramentas de resumo identificam entidades específicas no banco de dados gráfico e fornecem os links necessários para definir relacionamentos. Essa abordagem permite estender rapidamente os modelos de dados existentes em gráficos, tornando-os mais úteis como parte de um aplicativo baseado em IA. Ao mesmo tempo, você pode usar as APIs do Azure Open AI para adicionar um conjunto de incorporações aos seus dados, a fim de usar a pesquisa vetorial para explorar seus dados como parte de um fluxo de trabalho de estilo de agente usando LangChain ou Kernel Semântico.

Usando gráficos em IA: GraphRAG

O benefício real de usar um banco de dados gráfico com um modelo de linguagem grande vem com uma variação da abordagem RAG familiar, GraphRAG. Desenvolvido pela Microsoft Research, o GraphRAG usa gráficos de conhecimento para melhorar o fundamento em dados privados, indo além dos recursos de uma abordagem RAG padrão para usar o gráfico de conhecimento para vincular informações relacionadas e gerar respostas complexas.

Um ponto a ser entendido ao trabalhar com grandes quantidades de dados privados usando um LLM é o tamanho da janela de contexto. Na prática, é muito caro do ponto de vista computacional usar o número de tokens necessários para entregar muitos dados como parte de um prompt. Você precisa de uma abordagem RAG para contornar essa limitação, e o GraphRAG vai além, permitindo fornecer muito mais contexto em torno de sua consulta.

A pesquisa original do GraphRAG usa um banco de dados de notícias, que um RAG tradicional não consegue analisar de forma eficaz. No entanto, com um gráfico de conhecimento, entidades e relacionamentos são relativamente simples de extrair das fontes, permitindo ao aplicativo selecionar e resumir notícias que contenham os termos de pesquisa, fornecendo ao LLM muito mais contexto. Isso ocorre porque a estrutura do banco de dados gráfico agrupa naturalmente entidades semânticas semelhantes, ao mesmo tempo que fornece um contexto mais profundo nos relacionamentos codificados nos vértices entre esses nós.

Em vez de pesquisar termos semelhantes, como um mecanismo de pesquisa tradicional, o GraphRAG permite extrair informações de todo o conjunto de dados que você está usando, sejam transcrições de chamadas de suporte ou todos os documentos associados a um projeto específico.

Embora a pesquisa inicial utilize automação para construir e agrupar o gráfico de conhecimento, há a oportunidade de usar o Neo4j para trabalhar com data lakes massivos no Microsoft Fabric, fornecendo uma maneira de visualizar esses dados para que cientistas de dados e analistas de negócios possam criar seus próprios clusters, que podem ajudar a produzir aplicativos GraphRAG que são orientados tanto pelo que é importante para o seu negócio quanto pelos padrões subjacentes nos dados.

Ter uma base de dados gráfica como o Neo4j no Azure Marketplace dá-lhe uma ferramenta que o ajuda a compreender e visualizar as relações nos seus dados de uma forma que suporta tanto humanos como máquinas. Integrá-lo ao Fabric deve ajudar a construir aplicativos LLM em larga escala, com reconhecimento de contexto e permitindo que você obtenha resultados fundamentados de seus dados de uma forma que as abordagens RAG padrão podem perder. Será interessante ver se a Microsoft começará a implementar o GraphRAG em sua própria ferramenta Prompt Flow LLM.