Pular para o conteúdo

apps/infrastructure/qdrant

175 · Infraestrutura em Docker · ≈ 6 min de estudo

Qdrant — busca vetorial antifraude

Qdrant é um banco de dados vetorial: em vez de casar valores exatos, encontra os pontos mais parecidos com um vetor de consulta. Aqui ele responde uma pergunta que SQL não responde bem: esta transação se parece com fraudes que o time já confirmou? Use quando a decisão depende de semelhança de comportamento, não de um limiar fixo.

passos
6
arquivos
7
testes
0
tecnologias
4
Infraestrutura realTypeScriptBunQdrantDocker
Baixar cartão

Cenário

Uma fintech decide, no momento da autorização, se uma transação é fraude. O time antifraude revisou transações passadas e marcou cada uma como legítima ou fraudulenta. Cada uma vira um vetor de valor, hora, canal, distância da residência, dispositivo novo e risco do estabelecimento. Uma transação nova é comparada com esse histórico: vizinhos próximos que são fraudes confirmadas levam ao bloqueio. Uma onda de fraude de cartão de mais de um ano atrás, já encerrada, fica fora da janela de revisão e não pesa na decisão de hoje.

Planta

Fluxo
11/11
Histórico revisadolegítima ou fraude, com dataVetor de 8 dimensõesnormalizadas entre 0 e 1upsert com id UUID v5transactions_v1alias transactionsTransação novaquery no aliastop K vizinhosfiltro reviewed_atdentro da janela,campo indexadoscore = similaridadedas fraudesdividida pelasimilaridade totalscoreBLOCKREVIEWAPPROVEmaior ou igual 0.70.4 a 0.7menor que 0.4
11

11 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Busca vetorial antifraude (k-NN sobre transações)

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    transactionVector normaliza cada dimensão para 0..1 (valor em escala logarítmica, canal one-hot): nenhuma característica domina a distância cosseno

  2. 02

    fraudIndexBuild cria a coleção versionada (transactions_v1), indexa reviewed_at — o campo filtrado — e faz upsert com wait: true

  3. 03

    O id de cada ponto é UUID v5 do id da transação: reconstruir o índice atualiza os mesmos pontos, não duplica

  4. 04

    A aplicação só consulta o alias transactions; uma versão nova entra no ar trocando o alias numa chamada atômica

  5. 05

    transactionClassify busca os K vizinhos pela Query API, filtrando revisões dentro da janela

  6. 06

    O score pondera cada vizinho pela similaridade e decide BLOCK, REVIEW ou APPROVE; o Qdrant só responde com a API key

Trade-offs

O que se ganha, o que se paga

Abordagem Limite
Regras em SQL (valor > X AND hora < Y) Fraudador aprende o limiar e fica logo abaixo dele
Busca vetorial (k-NN) Compara o comportamento inteiro, mas depende de histórico revisado e de normalização correta
Coleção atrás de alias Reindexação sem downtime, ao custo de duas coleções em memória durante a troca

apps/infrastructure/qdrant

7 arquivos

src/

  • vector_transaction.tsTransação e seu vetor de 8 dimensões
  • history_fraud.tsHistórico revisado com data da revisão e transações a decidir
  • index_fraud.tsColeção versionada, índice de payload, upsert idempotente e troca de alias
  • detect_fraud.tsBusca k-NN com filtro de janela, score ponderado e decisão
  • config_qdrant.tsConfiguração validada do ambiente
  • demo.tsdemoIndexa, classifica e reconstrói como nova versão

./

  • docker.shinfraSobe o Qdrant com API key e espera o /readyz

Executar · com Docker

  1. ./docker.sh up# sobe Qdrant
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real

Dashboard: http://localhost:6333/dashboard (pede a API key do .env).

Requisitos
BunDocker
Sobe junto
Qdrant

Por que se relacionam

Teste rápido

Qual destes combina com Qdrant?

Próximo projeto · Infraestrutura em DockerRabbitMQ — liquidação de pagamentos com retry e DLQ
Esc

↑ ↓ navegarEnter abrir191 resultados