The all-in-one intelligent cloud (Sponsored)
Your app, live in seconds, for free. Railway’s push-button compute, storage, and networking is available immediately upon sign-up.
Humans and agents alike operate on one vertically integrated system including hardware, software, and a prompt-to-production experience.
Sign up with the link below for free cloud credits and let your agents cook.
This week’s system design refresher:
How to Test Your Code (Even When AI Writes It)
8 Chunking strategies for RAG-based agents
Google Translate: The Ideas Behind Neural Translation
Agent Skills, Clearly Explained
PostgreSQL versus MySQL
How to Test Your Code (Even When AI Writes It)
8 Chunking strategies for RAG-based agents
Fixed-Size: cuts text every fixed number of tokens, with a small overlap.
Recursive: splits on paragraphs first, falling back to lines then words and characters only when a piece is still too big.
Document-Based: splits wherever the document already marks a break, a heading, a chapter, an HTML tag, so a markdown file becomes one chunk per section on its own.
Semantic: embeds each sentence, checks its similarity to the one before it, and starts a new chunk when that similarity drops. This finds real topic shifts instead of guessing by length.
LLM-Based: asks an LLM to rewrite the text as standalone propositions, one idea per line, and turns each into a chunk, high quality but expensive across a large corpus.
Agentic: an AI agent reads each document, decides what it is (code, contract, table), and picks the chunking method for that file instead of one rule for everything.
Late Chunking: runs the full document through an embedding model, then applies normal split boundaries and mean-pools within each boundary to create chunk embeddings.
Hierarchical: breaks the document into layers, sections, paragraphs, then sentences
Over to you: which chunking strategy are you running in production?
Google Translate: The Ideas Behind Neural Translation
A simplified illustration of common techniques. Not an exact map of Google Translate’s current system.
Detect language. A tiny classifier predicts the source language in milliseconds.
Tokenization. A BPE tokenizer splits the text into subword tokens, so the model can handle any word in any language.
Add target token. The model can handle every language pair. A special token like <2es> is prepended to the token sequence to steer the output toward Spanish.
Encoder. The tokens pass through Transformer layers. The output is a sequence of vectors, corresponding to each input token.
Decoder. Then the decoder part of the Transformer can predict the probability distribution for the next token conditioned on the encoded vectors.
Beam search. Instead of greedily picking one token at a time, beam search uses the decoder to keep several candidate translations during generation. The final output is the one with the highest probability.
Over to you: Do you think AI labs and frontier models will make services like Google Translate obsolete?
Agent Skills, Clearly Explained
Why do we need Agent Skills? Long prompts hurt agent performance. Instead of one massive prompt, agents keep a small catalog of skills, reusable playbooks with clear instructions, loaded only when needed.
Here is what the Agent Skills workflow looks like:
User Query: A user submits a request like “Analyze data & draft report”.
Build Prompt + Skills Index: The agent runtime combines the query with Skills metadata, a lightweight list of available skills and their short descriptions.
Reason & Select Skill: The LLM processes the prompt, thinks, and decides: “I want Skill X.”
Load Skill into Context: The agent runtime receives the specific skill request from the LLM. Then, it loads SKILL. md and adds it into the LLM’s active context.
Final Output: The LLM follows SKILL. md, runs scripts, and generates the final report.
By dynamically loading skills only when needed, Agent Skills keep context small and the LLM’s behavior consistent.
Over to you: What skills would you find most useful in agents?
PostgreSQL versus MySQL
Built using the C language, PostgreSQL uses a process-based architecture.
You can think of it like a factory with a manager (Postmaster) coordinating specialized workers. Each connection gets its own process and shares a common memory pool. Background workers handle tasks like writing data, vacuuming, and logging independently.
MySQL takes a thread-based approach. Imagine a single multi-tasking brain.
It uses a layered design with one server handling multiple connections through threads. The magic happens using pluggable storage engines (such as InnoDB, MyISAM) that you can swap based on your needs.
Over to you: Which database do you prefer?
Worth flagging the main constraint on late chunking: the whole document has to fit in the embedding model's context window (8K tokens for the jina-embeddings-v2 models the original paper used). Past that you have to split into macro-chunks first, so you're back to choosing boundaries, just at a coarser level.
The payoff is real for reference-heavy text. Under fixed-size splitting, a chunk like "its revenue grew 3%" loses which company "its" means, while late chunking keeps that because every token was embedded with the full document in view. Curious whether anyone has measured agentic chunking against plain recursive splitting plus a reranker, since a good reranker often recovers most of what clever boundaries buy you.
Agentic chunking is the one I'd want a record for, not just a better split. The agent reads the file, decides it is a contract or a table, and picks the method, but retrieval later only sees the chunks. A contract clause cut on paragraph length and a table cut on rows then look the same in the index, and a bad answer can't be traced to that choice. I'd store the label and the splitter next to each chunk, so the next run can tell a wrong method from a weak embedding.