Estrutura de dados: a velha disciplina por trás da nova IA

No início da minha carreira, tanto como desenvolvedor (na época, programador), quanto depois como analista de sistemas, desenvolvi inúmeros projetos com bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. Hoje vejo uma correlação interessante entre aquele trabalho de analista de sistemas e o que entendemos atualmente como arquitetura: era preciso pensar não apenas no programa, mas na estrutura dos dados, nos relacionamentos, nos caminhos de acesso e nas consequências de cada decisão.

Uma área que me interessou particularmente foi estrutura de dados. Mergulhei em muitos livros sobre o assunto e, depois, tive a oportunidade de colocar esse conhecimento em prática trabalhando com sistemas como TOTAL, da Cincom, IMS, da IBM, Adabas, da Software AG, e SQL/DS, também da IBM, o irmão menor do DB2.

O interessante é que eles representavam diferentes respostas para um problema fundamental da computação: como organizar a informação para armazená-la, encontrá-la e processá-la de forma eficiente?

O TOTAL era um banco de dados de modelo de rede, baseado em registros relacionados por estruturas de owner/member sets. Um registro podia participar de diferentes conjuntos e, portanto, estar relacionado a mais de um registro proprietário. Isso permitia representar relacionamentos mais complexos do que uma estrutura hierárquica rígida e oferecia caminhos de navegação eficientes para os padrões de acesso previstos no projeto.

A contrapartida era importante: a aplicação precisava conhecer a estrutura dos relacionamentos e os mecanismos de navegação. O desenho dos dados tinha influência direta sobre a forma como os programas acessavam a informação.

O IMS, da IBM, seguia outra abordagem: o modelo hierárquico. Os dados eram organizados em segmentos relacionados por estruturas de pai e filho, formando uma árvore. Um database record lógico era constituído por uma ocorrência do segmento raiz e seus segmentos dependentes.

Essa organização podia ser extremamente eficiente quando a hierarquia e os padrões de acesso correspondiam ao problema que estava sendo modelado. Havia, porém, uma consequência arquitetural importante: a aplicação precisava conhecer a estrutura hierárquica e utilizar os mecanismos de navegação fornecidos pelo IMS. O modelo de dados influenciava diretamente a forma de acessar a informação.

Era uma época em que conhecer profundamente como os dados estavam organizados e como chegar até eles fazia parte essencial do trabalho do programador.

O Adabas me interessava por uma razão diferente. Sua arquitetura separava o armazenamento dos dados, no Data Storage, das principais estruturas de acesso mantidas no Associator. Entre elas estavam o Address Converter, que fazia o mapeamento entre o identificador lógico do registro, o ISN, e sua localização física, e as listas invertidas associadas aos campos definidos como descritores.

Essas listas invertidas são particularmente interessantes. Para os campos definidos como descritores, elas associavam valores aos ISNs dos registros correspondentes, permitindo que determinadas pesquisas fossem resolvidas sem a necessidade de percorrer todo o Data Storage. Isso acelerava significativamente certos padrões de consulta, mas tinha um custo: as estruturas de acesso ocupavam espaço e precisavam ser mantidas durante as atualizações.

É um princípio que continua absolutamente atual: não basta armazenar informação; é preciso criar estruturas que tornem determinados padrões de acesso eficientes.

Então veio o SQL/DS. A mudança conceitual foi enorme. O SQL/DS, lançado pela IBM em 1981, foi o primeiro sistema relacional comercial da IBM e incorporou a experiência acumulada no projeto experimental System R. O SQL permitia expressar consultas de forma declarativa, enquanto o SGBD assumia uma parcela muito maior da responsabilidade por determinar como os dados seriam acessados.

Isso alterou profundamente a relação entre aplicação e banco de dados. Nos modelos navegacionais, o programador precisava conhecer muito mais sobre como chegar aos dados. No modelo relacional, passou a descrever de forma mais declarativa quais dados queria obter, enquanto o SGBD podia escolher entre diferentes estratégias de acesso.

Isso não eliminou a importância da arquitetura física. Índices, organização dos dados, clustering, estatísticas e planos de execução continuaram sendo fundamentais para desempenho. A diferença é que a estratégia de acesso passou a ser, em maior medida, uma responsabilidade do SGBD e de seu otimizador.

Olhando hoje para essa trajetória, vejo uma conexão interessante com o que estamos fazendo com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. Embeddings, bancos vetoriais e RAG são tecnologias muito diferentes daquelas que utilizávamos décadas atrás. Não faz sentido tratá-las como versões modernas de IMS, TOTAL ou Adabas.

Mas existe uma continuidade importante no problema arquitetural: representação, indexação e recuperação da informação.

Nos bancos relacionais, índices permitem acelerar buscas sobre atributos estruturados. No IMS, a hierarquia organizava os caminhos naturais de acesso. No Adabas, listas invertidas permitiam recuperar registros a partir dos valores de determinados descritores.

Em uma arquitetura moderna de RAG, trechos de documentos podem ser transformados por modelos de embedding em representações vetoriais. Essas representações podem ser indexadas para permitir busca por similaridade, utilizando estratégias de nearest-neighbor e, em grandes volumes, métodos de approximate nearest neighbor.

A diferença é fundamental, pois não estamos mais procurando apenas uma correspondência exata ou uma relação explicitamente modelada. Estamos procurando proximidade em um espaço vetorial.

Mas aqui existe uma distinção que considero importante. Recuperação não é simplesmente indexação. Em um banco de dados tradicional, podemos pensar, de maneira simplificada, em uma cadeia entre estrutura de dados, índice, busca e registro. Em um sistema de RAG, a cadeia é bem mais complexa: documento → segmentação → embedding → indexação → recuperação → ranking → contexto → modelo → resposta ou ação.

Cada etapa pode introduzir erros ou perdas de informação. Uma estratégia inadequada de segmentação pode separar informações que deveriam permanecer juntas. Um embedding pode não representar adequadamente uma distinção importante para determinado domínio. A recuperação pode trazer documentos semanticamente próximos, mas pouco relevantes. O ranking pode priorizar o contexto errado. E o modelo pode então produzir uma resposta perfeitamente coerente baseada em evidências inadequadas.

Ou seja, o erro pode acontecer antes de o LLM produzir qualquer token. Essa é uma diferença importante em relação à forma como muitas vezes discutimos IA. Quando uma resposta está errada, a tendência é culpar imediatamente o modelo. Mas, em uma arquitetura de RAG, o problema pode estar na própria cadeia de informação que alimentou o modelo.

Por isso, RAG não é simplesmente “um LLM conectado a um banco vetorial”. É uma arquitetura de informação, recuperação, contexto e geração, na qual cada camada influencia a qualidade do resultado.

E aqui aparece outra diferença importante em relação aos bancos tradicionais: similaridade semântica não é sinônimo de relevância contextual. Dois conteúdos podem estar próximos no espaço vetorial e ainda assim um deles ser inadequado para determinada decisão. A recuperação pode trazer informação semanticamente relacionada, mas incompleta, desatualizada ou insuficiente para o contexto necessário.

Essa perspectiva ajuda a entender por que estrutura de dados sempre foi uma questão arquitetural.

No IMS, a hierarquia condicionava os caminhos naturais de acesso. No TOTAL, os relacionamentos em rede permitiam múltiplos caminhos entre registros. No Adabas, descritores e listas invertidas criavam estruturas especializadas para determinados padrões de busca. No modelo relacional, a separação entre modelo lógico e estratégia física de acesso permitiu ao SGBD assumir uma parcela maior dessa decisão.

Hoje, com embeddings e recuperação semântica, estamos novamente escolhendo como representar informação e como torná-la recuperável. Só que agora existe uma camada adicional: a representação semântica.

Durante muito tempo, aprendi que uma estrutura de dados não é apenas uma forma de guardar informação. Ela condiciona aquilo que será mais fácil ou mais difícil encontrar, relacionar e processar depois.

Essa lição continua válida. A diferença é que, antes, desenhávamos estruturas principalmente para que programas encontrassem e processassem informação. Agora também desenhamos estruturas para que modelos probabilísticos encontrem contexto e, a partir dele, produzam respostas ou executem ações.

Por isso continuo acreditando que estudar estruturas de dados foi uma das melhores formações que tive na carreira. As tecnologias mudam. Mas as consequências de uma decisão arquitetural ruim continuam. Na era da IA, elas apenas podem se propagar em uma escala muito maior.