Tag: til

I went down a rabbit hole comparing four ways to turn unstructured documents into structured data: full LLM inference, fine-tuned small models, template-based extraction, and cloud OCR. The cost spread floored me. A template reads a document for about $0.001, where full LLM inference runs $5 to $15 on the same PDF and the same fields. Most teams pay LLM prices for forms a regex could handle. Classify each document upfront, route it to the cheapest tool that can do the job, and you cut costs 85% while keeping the big model in reserve for the genuinely weird formats.

I went down a semantic layer rabbit hole recently, so here are the notes before they evaporate. It's the translation layer between your raw data and the people asking questions of it: define "revenue" once and it means the same thing in SQL, MDX, DAX, an API, and now your AI agents, which kills most of the governance drama before it starts. Risk is the real draw. Every extract into a cube or data mart leaves a stale copy to govern and one more surface to breach, which is why the vendors that build aggregates in place, like AtScale on Databricks, are the ones worth watching.

Today I learned you test LinkedIn sharing in production, because there's nowhere else to test it. LinkedIn's crawler scrapes your Open Graph tags once and caches them, so fixing a typo afterward just leaves a stale preview with no error and no warning, and clearing your own browser cache does nothing because the cache lives on their servers. Debugging it feels like working through a one-way mirror while wearing oven mitts. You can't even test it locally. The crawler never reaches localhost. The workarounds are LinkedIn's Post Inspector, a ?v=2 cache-bust on the URL, and double-checking that your Django Site domain is right.

I used to picture multi-head attention as cutting the embedding into pieces, one slice per head. That's wrong. Every head reads the whole input embedding, all 768 dimensions of it, and projects it down through its own learned weights. No head works with less of the input. What separates the heads is learned, not carved out of the embedding.

Today I learned why Flask's request context object is called g, and it's too clever by half. It stands for global, but the joke is that it's request-local: each request gets its own isolated g, so you get global-like access without the race conditions a real shared global would hand you. Armin Ronacher chose it on purpose. It's quick to type, since you reach for it constantly, and it reads as obviously special, the same way e reads as an exception.

AWS DMS (Database Migration Service) gets overlooked as a CDC tool because the marketing is all about migrations. For simple change data capture it works well, and it barely needs configuring thanks to native Aurora Postgres support. I reach for something heavier only when the requirements get sharp.

I kept seeing reranking in RAG discussions and finally clicked that it's a specific technique, not a vague concept. Your fast initial retrieval grabs a batch of candidate documents, then a slower, sharper model re-scores just those and reorders them before the LLM ever sees them. That second pass is where you can factor in recency or source authority that would melt your servers if you ran it across the whole corpus.