|
In today's newsletter:
- Two skills to fix the context gap in Claude Code.
- Naive RAG vs Blockify, explained visually.
- DevOps vs. MLOps vs. LLMOps.
|
|
|
Hands-on
Claude Code has two context gaps that no amount of CLAUDE.md optimization will fix.
The first is web scraping.
web_fetch doesn’t return raw page content. It runs the page through a smaller model and returns a summary with a 125-character quote limit, so you can’t use it to extract full tutorials, product specs, or thread content.curl returns raw HTML but gets blocked by sites with anti-bot protection (Amazon, LinkedIn, most e-commerce), can’t render JavaScript SPAs, and fails at scale due to rate limiting. Both truncate at around 100KB.
The second is backend integration.
- When Claude Code talks to a backend like Supabase through MCP, it discovers state through multiple separate calls (
list_tables, execute_sql, list_extensions), each returning a partial view.
- Auth provider config isn’t queryable at all. And when something fails, error messages don’t distinguish between platform-level and code-level rejections, so the agent enters retry loops that burn tokens with every attempt. In our recent test, a single RAG app built on Supabase consumed 10.4M tokens and needed 10 manual fixes.
Bright Data solves the first problem. InsForge solves the second.
Today, let’s look at how to set up both as skills in Claude Code, with an interesting way we tend to use them.
Bright Data setup
Bright Data skill (open-source) adds scraping infrastructure that handles everything web_fetch and curl can’t.
The agent gets a four-tier fallback that escalates based on what the target site requires, like native fetch, curl, browser automation, and a proxy network with residential IPs and automatic CAPTCHA solving.
For agent workflows, the more useful capability is structured data extraction.
Instead of raw HTML that the agent has to parse, Bright Data provides pre-built extractors for 40+ platforms (Amazon, LinkedIn, Instagram, TikTok, YouTube, Reddit) that return clean JSON with specific fields like product prices, review scores, profile data, and post content.
This installs several skills covering scraping, search, structured data feeds, MCP orchestration, SDK best practices, and the bdata CLI.
InsForge setup
We covered the backend problem in depth in a recent issue. The same RAG app that consumed 10.4M tokens on Supabase consumed 3.7M on InsForge with zero errors.
InsForge (open-source, Apache 2.0) acts as the backend context engineering layer for agents using Skills and CLI.
- Install all four Skills (primary documentation and diagnostic layer):
This installs insforge (SDK patterns), insforge-cli (infrastructure commands), insforge-debug (failure diagnostics), and insforge-integrations (third-party auth providers). Total metadata cost: ~714 tokens at session start.
- Link the CLI to your project (primary execution layer):
Building a Google Doc clone
This 10 hr video teaches how to build a Google Doc clone:
Ten hours of video means hundreds of implementation details like real-time collaboration, document state syncing, editor toolbar structure, and permissions.
That’s a lot of context that Claude Code will likely struggle to scrape. Even if it manages to scrape, compression will remove many of those details.
With both skills installed, here’s what you can do:
The video below depicts the whole build with the final app, built in one shot:
- Bright Data scraped the full video content (transcript, metadata, structured descriptions), and Claude Code used it as the build spec.
- InsForge handled the backend in one shot: Google OAuth, database schema with RLS, storage, edge functions, and the model gateway for GPT-4o chat through InsForge’s built-in functionalities.
Finally, it gave a working Google Docs clone with real-time editing, Google OAuth, and AI-powered document chat, built from a single prompt with zero errors.
The YouTube example is the simple case for the scraping side and this isn't limited to tutorials or building from scratch.
The same workflow applies to any technical content on the web, like:
- A Reddit thread where someone describes how they optimized their real-time sync.
- A Hacker News discussion walking through an auth architecture.
- A competitor's product page with a feature worth replicating.
Give the link to Claude Code with the Bright Data skill, and the agent scrapes the content, understands what was described, and implements it in the existing app.
So any technical content on the web can become a build spec.
For basic sources, native scraping tools work. Bright Data is essential with sources that actively resist scraping, like Reddit threads with aggressive rate limiting, Amazon product pages behind anti-bot detection, LinkedIn profiles that fingerprint your browser, and JavaScript SPAs that need full browser rendering to even load content.
👉 Over to you: what skills live in your default Claude Code setup?
|
|
|
open-source
There’s a new RAG approach that:
- cuts corpus size by 40x.
- reduces tokens per query by 3x.
- improves vector search relevance by 2.3x.
And it delivered 260% accuracy improvement on the medical RAG benchmark over standard RAG.
The diagram compares it with naive RAG:
Chunks in a standard RAG pipeline typically carry no info about version, clearance level, or source authority.
The embedding model encodes it the same way regardless of whether the chunk is an outdated draft or the latest approved version.
During retrieval, if an outdated chunk and a latest chunk get retrieved as context, the LLM has no signal to prefer one over the other.
So it combines both and hallucinates.
The issue is not retrieval but rather the representation. The unit itself is wrong, and the fix has to happen before retrieval, at the data layer.
Blockify is an open-source data preprocessing engine that solves this at the data layer.
The engine sits between the document parser and the vector store.
Here’s how it works:
- First, a context-aware splitter finds natural breaks (paragraph boundaries, section breaks, topic shifts).
- Instead of embedding raw segments directly, a purpose-built LLM processes each one and extracts structured knowledge units called IdeaBlocks (typically 2-3 sentences). Each unit isolates a different fact or concept.
- Each unit is paired with a contextualized question and answer. This mirrors how users query the system and ensures the query embedding sits closer to real queries in the vector space (HyDE does something similar).
- Each block also carries metadata info like entity name, entity type, version, and clearance level. This helps rank retrieval by recency and authority, not just similarity.
The pipeline runs in two stages.
- The Ingest model converts raw text into IdeaBlocks as described above.
- The Distill model then clusters semantically similar blocks across the full set and merges duplicates into one canonical unit before indexing.
The retrieved units now answer a specific question instead of returning a paragraph that might contain the answer somewhere in the middle.
On the published benchmarks:
- The pipeline reduces a corpus to roughly 2.5% of its original size while preserving 99% factual integrity.
- Token consumption per query drops by 3x, from 1.5k tokens (naive top-5 chunks) to 500 tokens (top-5 IdeaBlocks).
- Vector search relevance improves 2.3x, measured by cosine distance.
In medical evaluation, the same pipeline delivered up to 650% accuracy improvement on clinical-grade RAG with a quantized Llama 3.2 3B model running on-device.
Blockify composes with LangChain and LlamaIndex. You can swap out the chunking stage (NodeParser/TextSplitter) and produce IdeaBlock nodes that the rest of the pipeline consumes normally.
For storage, you can integrate it directly with most vector DBs like Milvus, Elastic, etc.
There is also a Claude Code skill in the repo that runs the full Ingest and Distill pipeline while referencing the project documentation.
For production workloads on Intel Xeon, an optimized build is available through OpenVINO.
Here’s the GitHub repo →
|
|
|
pipelines
Many teams are trying to apply DevOps practices to LLM apps.
But DevOps, MLOps, and LLMOps solve fundamentally different problems, and this visual summarizes this:
Let’s dive in to learn more!
On a side note, we have already covered MLOps from a fully beginner-friendly perspective in our 18-part course.
It covers foundations, ML system lifecycle, reproducibility, versioning, data and pipeline engineering, Spark, model compression, Deployment phase, Kubernetes, cloud infra, virtualisation, deep dive into AWS, and monitoring in production.
DevOps is software-centric. You write code, test it, and deploy it. The feedback loop is straightforward: Does the code work or not?
MLOps is model-centric. Here, you’re dealing with data drift, model decay, and continuous retraining. The code might be fine, but the model’s performance can degrade over time because the world changes.
LLMOps is foundation-model-centric. Here, you’re typically not training models from scratch. Instead, you’re selecting foundation models and then optimizing through three common paths:
- Prompt Engineering
- Context/RAG Setup
- Fine-Tuning
But here’s what really separates LLMOps: The monitoring is completely different.
In MLOps, you track data drift, model decay, and accuracy.
In LLMOps, you’re watching for:
- Hallucination detection
- Bias and toxicity
- Token usage and cost
- Human feedback loops
This is because you can’t just check if the output is “correct.” You need to ensure it’s safe, grounded, and cost-effective.
The evaluation loop in LLMOps also feeds back into all three optimization paths simultaneously. Failed evals might mean you need better prompts, richer context, OR fine-tuning.
So it’s not a linear pipeline anymore.
Lastly, the cost dimension in LLMOps is wildly underestimated.
In DevOps, compute costs are typically predictable. In LLMOps, a bad prompt can 10x your token spend overnight. We have seen teams blow through monthly budgets in days because they ignored token usage per query.
If you want to start with MLOps, we have already covered MLOps from a fully beginner-friendly perspective in our 18-part course.
It covers foundations, ML system lifecycle, reproducibility, versioning, data and pipeline engineering, Spark, model compression, Deployment phase, Kubernetes, cloud infra, virtualisation, deep dive into AWS, and monitoring in production.
Start with MLOps Part 1 here →
We also published an LLMOps course recently.
It covers the fundamentals of AI engineering & LLMs, Building blocks of LLMs like tokenization, embeddings, attention, architectural designs and training, decoding, generation parameters, the LLM Application Lifecycle, context engineering, prompt management, defense, control, memory, temporal context, evaluation, tool use, red teaming, Adaptive LLMs, and Serving.
Start with LLMOps Part 1 here →
👉 Over to you: What does your LLM monitoring stack look like right now?
|
|
|
Partner with US
ADVERTISE TO 950k+ AI Professionals
Our newsletter puts your products and services directly in front of an audience that matters, including thousands of leaders, senior data scientists, machine learning engineers, data analysts, etc., around the world.
Get in touch today by replying to this email.
|
|
|
