aprendendo NLP sem uma base sólida em DSA (e pagando o preço disso)

I picked NLP as the first serious topic in my AI Engineering track. It made sense: I was already going to use spaCy at work, I had an NLP course running on Udemy alongside the official documentation tutorial, and the subject connected directly to what I needed to deliver. The problem showed up a bit later, when I noticed I was getting to the right output without understanding why it worked that way.

the symptom

At first, everything seemed fine. doc = nlp(text), iterate over the tokens, grab .pos_, .dep_, .ent_type_, build the logic on top of that. The course kept moving, the exercises kept passing, the code kept running. But when it came to real token manipulation: filtering, regrouping, walking the dependency tree, optimizing a scan that needed to run over real volumes of text, I got stuck. Not because I didn't understand NLP. Because I didn't understand data structures.

That's when it clicked: a spaCy Doc is an optimized data structure. Tokens live as views over a contiguous buffer of numeric data (the Vocab and its string hashes), and each Token is essentially an index into that structure. Manipulating it efficiently is, in practice, the same kind of reasoning as manipulating an array in pure DSA: understanding access cost, slicing cost, when you're copying data versus just pointing at it, when an iteration is O(n) and when it turns into O(n²) because you didn't notice you'd stuffed a linear search inside a loop.

I just never had that solidified. And the reason is pretty direct: my college never delivered a decent DSA foundation. I took the course, got the grade, moved on, but the real content of "how to think about complexity, structures, and trade-offs" never stuck.

DSA and NLP in parallel

The solution I landed on wasn't pausing NLP to "come back later with a better foundation." That would push the practical application into an uncertain future, and I already had deliverables at work. Instead, I started studying both things in parallel, on purpose:

NLP/spaCy keeps moving: course, documentation, direct application in the project.
DSA came in as its own track, studied in parallel, specifically to support what spaCy demands in practice: understanding how a sequence of tokens behaves as a data structure, what it means to manipulate a Span, why slicing a Doc is different from slicing a plain Python list, and how to think about complexity when the input is real text, not a toy array from an intro course.

On that front, Augusto Galego's DSA course has been the piece helping the most so far. It's the material that's actually filling the hole college left, not just teaching data structures in the abstract, but in a way I can pull straight into the reasoning I use on spaCy.

That means studying both subjects with the other in mind the whole time. Every time a DSA concept comes up (arrays, pointers, sliding windows, searches), I immediately try to map it to some real operation I do on spaCy tokens. And every time I hit a wall manipulating tokens, that's the signal for which DSA gap I need to close first.

why this matters

You can use a library like spaCy without understanding any of this: it's built to be that way, high-level enough to work like that. The problem is that without this foundation, you're at the mercy of whatever the library already solved for you. The moment the real application asks for something outside the documentation's happy path: a pattern extraction that needs to be efficient at volume, a span manipulation that isn't trivial, a decision between rebuilding a structure or navigating in place, the lack of DSA turns into a pretty low ceiling, pretty fast.

And that's especially true when the context is applied, not academic. It's about a pipeline that processes real documents, at real volume, within a real sprint deadline.

where that leaves me now

I'm still in this uncomfortable middle ground: solid enough in NLP to be productive, but rebuilding underneath the structure that should have come first. The DSA track runs alongside work, and the measure of progress is internalizing the structure-and-complexity reasoning that should have been the foundation before any AI work at all.

If this phase is making anything clear, it's that "learning AI" without this foundation is personal technical debt, and it charges interest exactly when you most need the code to actually work well: in production, on real data.

One good thing already coming out of this: I'm starting a DSA club at work with an Android specialist from my department who's become a friend along the way. He feels the same gap I do, just on the Android side, and studying this as a group has a better shot at actually sticking than studying alone.

Escolhi NLP como primeiro tópico sério da minha trilha de AI Engineering. Fazia sentido: eu já ia usar spaCy no trabalho, tinha curso de NLP andando na Udemy em paralelo com o tutorial oficial da documentação, e o assunto conectava direto com o que eu precisava entregar. O problema apareceu um pouco depois, quando percebi que estava conseguindo chegar no resultado sem entender por que aquilo funcionava daquele jeito.

o sintoma

No começo, tudo parecia ir bem. doc = nlp(texto), itera nos tokens, pega .pos_, .dep_, .ent_type_, monta a lógica em cima disso. O curso avançava, os exercícios passavam, o código rodava. Só que na hora de aplicar isso em manipulação de token de verdade: filtrar, reagrupar, navegar pela árvore de dependência, otimizar uma varredura que precisava rodar em cima de volumes reais de texto, eu travava. Não porque não entendia NLP. Porque não entendia estrutura de dados.

E aí caiu a ficha: um Doc do spaCy é uma estrutura de dados otimizada. Os tokens vivem como views sobre um buffer contíguo de dados numéricos (o Vocab e os hashes de string), e cada Token é essencialmente um índice nessa estrutura. Manipular isso com eficiência é, na prática, o mesmo tipo de raciocínio que manipular um array em DSA pura: entender custo de acesso, custo de slicing, quando você está copiando dado e quando está só apontando pra ele, quando uma iteração é O(n) e quando ela vira O(n²) porque você não percebeu que enfiou uma busca linear dentro de um loop.

Só que eu nunca tive isso solidificado. E o motivo é bem direto: minha faculdade não entregou uma base decente de DSA. Passei pela disciplina, tirei nota, segui em frente, mas o conteúdo real de "como pensar em complexidade, estruturas e trade-offs" simplesmente não ficou.

DSA e NLP em paralelo

A solução que encontrei não foi pausar o NLP pra "voltar depois com uma base melhor". Isso empurraria a aplicação prática pra um futuro incerto, e eu já tinha entrega no trabalho. Em vez disso, passei a estudar as duas coisas em paralelo, de propósito:

NLP/spaCy continua andando: curso, documentação, aplicação direta no projeto.
DSA entrou como trilha própria, estudada em paralelo, especificamente pra sustentar o que o spaCy exige na prática: entender como uma sequência de tokens se comporta como estrutura de dados, o que significa manipular um Span, por que fatiar um Doc é diferente de fatiar uma lista Python comum, e como pensar em complexidade quando a entrada é texto real, não um array de brinquedo de curso introdutório.

Nessa frente, o curso de DSA do Augusto Galego tem sido a peça que mais está ajudando até agora. É o material que está realmente preenchendo o buraco que a faculdade deixou, não só ensinando estrutura de dados no abstrato, mas de um jeito que eu consigo puxar direto pra dentro do raciocínio que uso no spaCy.

Isso significa estudar os dois assuntos com o outro em mente o tempo todo. Toda vez que um conceito de DSA aparece (arrays, ponteiros, janelas deslizantes, buscas), eu tento imediatamente mapear pra alguma operação real que faço em cima de tokens do spaCy. E toda vez que esbarro numa limitação na hora de manipular tokens, esse é o sinal de qual buraco de DSA eu preciso fechar primeiro.

por que isso importa

Dá pra usar uma biblioteca como o spaCy sem entender nada disso: ela é feita pra isso, é de alto nível o suficiente pra funcionar assim. O problema é que sem essa base, você fica refém do que a biblioteca já resolveu pra você. No momento em que a aplicação real pede algo fora do caminho feliz da documentação: uma extração de padrão que precisa ser eficiente em volume, uma manipulação de span que não é trivial, uma decisão entre reconstruir uma estrutura ou navegar in-place, a ausência de DSA vira um teto bem baixo, bem rápido.

E isso é especialmente verdade quando o contexto é aplicado, não acadêmico. É sobre um pipeline que processa documento real, com volume real, dentro de um prazo real de sprint.

onde isso me deixa agora

Ainda estou nesse meio-termo pouco confortável: sólido o suficiente em NLP pra ser produtivo, mas reconstruindo por baixo a estrutura que deveria ter vindo antes. A trilha de DSA anda junto com o trabalho, e o critério é internalizar o raciocínio de estrutura e complexidade que devia ter sido a base antes de qualquer coisa de IA.

Se tem algo que essa fase está deixando bem claro é que "aprender IA" sem essa base é dívida técnica pessoal, e ela cobra juros exatamente na hora em que você mais precisa que o código funcione bem: em produção, com dado de verdade.

Uma coisa boa que já está saindo desse processo: vou começar um clube de DSA no trabalho com um especialista em Android do meu departamento que virou amigo no caminho. Ele sente o mesmo buraco que eu, só que do lado Android, e estudar isso em grupo tem mais chance de virar hábito de verdade do que estudar sozinho.