MariaDB e IA: tokens, embeddings, vetores e RAG explicados

Todo mundo fala de IA, RAG e "banco vetorial" como se fosse óbvio. Não é. Eu mesmo, depois de décadas mexendo com banco de dados, precisei parar, desenhar no papel e apanhar um pouco até a ficha cair. Então vamos do zero, sem pular etapa, e no final você vai entender exatamente onde o MariaDB entra nessa história.

Nuvem de pontos com as palavras café, coffee e kaffee próximas entre si ao lado de um servidor

O mapa da viagem

"Quero um café forte"
        │
        ▼
 [1] Tokenização  →  ["Quero", " um", " café", " forte"]
        │
        ▼
 [2] IDs          →  [48291, 1012, 30877, 22145]
        │
        ▼
 [3] Embedding    →  [0.021, -0.334, 0.118, ... ]  (ex.: 768 números)
        │
        ▼
 [4] MariaDB      →  coluna VECTOR(768) + VECTOR INDEX
        │
        ▼
 [5] Busca        →  "quem está mais perto deste vetor?"

1. Tokens: o modelo não lê palavras

Modelo de IA não enxerga letras nem palavras. Ele enxerga tokens: pedaços de texto que podem ser uma palavra inteira, parte dela ou até um espaço com pontuação. "Banco" pode ser um token; "inconstitucionalmente" pode virar quatro ou cinco.

Cada token tem um número de identificação no vocabulário do modelo. Pense num dicionário gigante onde cada pedaço de texto tem um "número de matrícula". É só isso. O ID não tem significado: o 30877 não está "perto" do 30878 em sentido nenhum.

Dica de quem paga a conta: APIs de IA cobram por token. Texto em português costuma gerar mais tokens que o mesmo texto em inglês, porque os vocabulários foram treinados com mais inglês.

2. Embeddings: onde o significado aparece

Aqui está a mágica. Um modelo de embedding pega o texto (já tokenizado) e devolve uma lista fixa de números, por exemplo 768 ou 1536. Essa lista é o embedding, e ela representa o sentido do texto como uma posição num espaço de muitas dimensões.

Imagine um mapa. Só que, em vez de latitude e longitude (2 dimensões), são 768 eixos. Textos com significado parecido caem perto uns dos outros. "Notebook leve para viagem" fica vizinho de "laptop fino para levar no avião", mesmo sem nenhuma palavra em comum.

3. Vetor: o nome técnico da lista de números

Vetor é simplesmente essa lista ordenada de números. Embedding é o vetor que carrega significado. Na prática, todo mundo usa os dois termos como sinônimos, e tudo bem.

"café"    → [ 0.81, 0.12, -0.40, ... ]
"coffee"  → [ 0.79, 0.15, -0.38, ... ]   ← quase igual
"pneu"    → [-0.22, 0.90,  0.05, ... ]   ← longe

(Números ilustrativos, para mostrar a ideia.)

4. Distância: como medir "parecido"

Se textos viram pontos num espaço, "parecido" vira "perto". As medidas mais comuns:

Cosseno: compara a direção dos vetores, ignorando o tamanho. É a mais usada para texto.
Euclidiana: a régua tradicional, distância em linha reta.

No MariaDB elas existem como funções: VEC_DISTANCE_COSINE() e VEC_DISTANCE_EUCLIDEAN(). Quanto menor o resultado, mais parecido.

5. Por que funciona em qualquer idioma

Modelos de embedding multilíngues são treinados com textos paralelos em dezenas de idiomas. O efeito é que "café", "coffee" e "Kaffee" aprendem a morar no mesmo bairro do mapa. O conceito vale mais que a grafia.

Consequência prática: você cadastra o catálogo em português e o cliente pesquisa em espanhol ou inglês, e a busca continua achando. Atenção: isso depende do modelo escolhido, não do banco. O MariaDB só guarda e compara números; quem "fala idiomas" é o modelo.

6. Aproximação: por que não comparar com tudo

Comparar sua pergunta com um milhão de vetores, um por um, é exato mas lento. A saída é a busca aproximada de vizinhos (ANN): um índice que organiza os vetores em grafo e encontra os mais próximos visitando só uma fração deles.

O MariaDB usa uma variação do HNSW (Hierarchical Navigable Small World). Pense numa rede de rodovias: primeiro você pega a estrada principal até a região certa, depois as ruas do bairro. Você troca um pouquinho de precisão (pode errar um vizinho de vez em quando) por uma velocidade enorme. Detalhei o índice em MariaDB Vector: busca vetorial com índice HNSW.

7. RAG: dar memória ao modelo

LLM sabe muito, mas não sabe do seu catálogo, do seu manual, do seu contrato. RAG (Retrieval-Augmented Generation) resolve assim:

Pergunta do usuário
   │ embedding
   ▼
MariaDB: busca os K trechos mais próximos   ← Retrieval
   │
   ▼
Prompt = pergunta + trechos encontrados      ← Augmented
   │
   ▼
LLM responde baseado nos trechos             ← Generation

Menos alucinação, resposta com fonte e sem precisar re-treinar modelo nenhum.

8. Como isso fica guardado no MariaDB

Desde a série 11.7, o MariaDB tem tipo VECTOR e índice vetorial nativos. Seus dados e seus embeddings ficam na mesma tabela, com transação, backup e replicação que você já conhece:

CREATE TABLE documentos (
  id        INT PRIMARY KEY AUTO_INCREMENT,
  texto     TEXT NOT NULL,
  embedding VECTOR(768) NOT NULL,
  VECTOR INDEX (embedding) M=8 DISTANCE=cosine
);

-- inserindo (o vetor vem do seu modelo de embedding)
INSERT INTO documentos (texto, embedding)
VALUES ('Café especial torra média', VEC_FromText('[0.81,0.12,-0.40, ...]'));

-- os 5 mais parecidos com a pergunta
SELECT id, texto
FROM documentos
ORDER BY VEC_DISTANCE_COSINE(embedding, VEC_FromText(@pergunta))
LIMIT 5;

Sem banco extra, sem sincronizar dois sistemas. Para mim, esse é o argumento mais forte.

Resumo de bolso

Token: pedaço de texto com um ID. Sem significado.
Embedding/vetor: lista de números que representa o sentido.
Distância: perto = parecido.
ANN/HNSW: achar os vizinhos rápido, aceitando aproximação.
RAG: buscar contexto no banco antes de perguntar ao modelo.
MariaDB: guarda e busca tudo isso com SQL.

No próximo passo a gente põe a mão na massa: RAG de recomendação de produtos no MariaDB, do CREATE TABLE ao SELECT. E se você ainda está no MySQL, veja como migrar do MySQL para o MariaDB. Tudo sobre MariaDB fica em /mariadb.

Sobre o autor: Alexandre Almeida é MariaDB Ambassador no Brasil, autor do livro Aprendendo MySQL e trabalha com bancos de dados há mais de 30 anos.

Fontes: MariaDB Knowledge Base: Vector Overview, CREATE TABLE with Vectors e Vector Functions (mariadb.com/kb). Malkov e Yashunin, "Efficient and robust approximate nearest neighbor search using HNSW graphs" (2016). Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020). Imagem: ilustração gerada por IA.