Archive
1046 posts · Page 33 of 88. ← Blog
Building RAG's retrieval core with watsonx.ai from Python — turning a corpus into vectors with IBM's slate embedding models, scoring a query against them, and then sharpening the shortlist with a reranking model so the LLM gets the right passages, not just plausible ones.
Use watsonx.ai's slate embedding models and reranking from Python to build RAG's retrieval core: embed_documents vs embed_query, numpy cosine scoring, and a two-stage retrieve-then-rerank pipeline — plus the langchain-ibm WatsonxEmbeddings/WatsonxRerank path.
Building RAG's retrieval core in Python — turning a corpus and a query into vectors with NeMo Retriever embedding NIMs, scoring by cosine similarity, then sharpening the shortlist with a cross-encoder reranker NIM.
Use NeMo Retriever from Python to build RAG's retrieval core: NVIDIAEmbeddings (embed_documents vs embed_query for the asymmetric passage/query distinction) with cosine scoring, and NVIDIARerank.compress_documents for a two-stage retrieve-then-rerank pipeline.
How to query a Knowledge Base for Amazon Bedrock from Go — the managed retrieve-then-read layer — using both the low-level Retrieve call and the one-shot RetrieveAndGenerate, with citations wired through.
RAG on Bedrock in Go with Knowledge Bases: the retrieve-then-read pattern via Retrieve, the one-shot managed path via RetrieveAndGenerate with citations, and when to reach for each — plus reading grounding so you keep RAG's trust benefit.
How to know whether an LLM system actually works — building an eval dataset, the four metric families (deterministic checks, text overlap, embedding similarity, LLM-as-judge) in Go, task-specific eval for RAG and classification, and wiring a scored regression gate into CI so you measure instead of vibe.
How to know whether an LLM system works when outputs are non-deterministic: build an eval dataset, score with deterministic checks, embedding similarity, and LLM-as-judge (with its biases), evaluate RAG and classification, and gate regressions in CI.
How to wire agent evaluations into continuous integration in Go — running a slow, model-calling eval harness under `go test`, setting per-metric thresholds that fail the build on a regression, and living honestly with the fact that these gates are softer than unit tests.
How to wire agent evaluations into continuous integration in Go — running a slow, model-calling eval harness under `go test`, setting per-metric thresholds that fail the build on a regression, and living...
The magic that makes an RPC feel like a local function call is code generation. You run a compiler over your `.proto` file and out come typed classes and methods for your language — the client stub you call and the server interface you implement. Understanding what's generated, and the boundary between generated and hand-written code, is what turns gRPC from a black box into a tool you control.
The magic that makes an RPC feel like a local function call is code generation. Run a compiler over your .proto and out come typed classes and methods — the client stub you call and the server interface you implement. Understanding what's generated, and the boundary between generated and hand-written code, turns gRPC from a black box into a tool you control.
Test-time compute reframes a question engineers rarely had to ask before: how much is a correct answer worth? Because thinking now costs money and time in direct proportion to how much of it you do, reasoning is no longer free — it's a purchase. A reasoning model can generate many times more tokens working through a problem than a standard model uses to answer it, and you pay for every one. Deciding when that's worth it is the core practical skill of the reasoning era.
Test-time compute reframes a question engineers rarely had to ask: how much is a correct answer worth? Thinking now costs money and time in direct proportion to how much of it you do. A reasoning model can generate many times more tokens than a standard model — and you pay for every one.
Getting great results from Claude Code is less about clever prompts and more about a disciplined loop: give context, specify clearly, let it work, review, and steer.
The disciplined loop that gets great results: explore → plan → execute → review, specifying like you'd brief a colleague, steering actively, managing context, and right-sizing delegation to the checks (tests) the agent can loop against.
The problem a customer first describes is almost never the problem worth solving — an FDE's first job is to dig until the real one surfaces.
The problem a customer first states is rarely the one worth solving: discovery techniques (ask why, watch real work, find the decision), the jobs-to-be-done lens, mapping stakeholders and constraints, and writing a confirmed problem frame.
Before you attack an AI system you need a map of it: the components an adversary can influence, the trust boundaries between them, and a taxonomy that sorts attacks by goal and stage so your red-teaming is systematic instead of a grab-bag of the attacks that happen to trend that week.
Mapping the AI attack surface so red-teaming is systematic: threat-modeling the components (model, prompts, training/RAG data, tools, guardrails) and an attack taxonomy by goal (integrity/availability/privacy/abuse) and stage (training vs inference), aligned to NIST AI 100-2 and ATLAS.
A trade-off-driven tour of the major ways to structure a system — monolith, modular monolith, layered, microservices, service-based, event-driven, and serverless — and how to choose one by team, scale, and organizational maturity rather than hype.
The major ways to structure a system and their trade-offs: the modular monolith (the underrated default), layered, microservices (and their heavy costs), event-driven, and serverless — chosen by team topology and scale (Conway's Law), not hype.
A reviewer's mental checklist ordered by leverage — design first, then correctness, then tests, then readability, with style and formatting handed off to the tools that were built for it.
A reviewer's checklist ordered by leverage: design first, then correctness and edge cases, then tests, then readability — and what to leave entirely to tools (formatting, lint) so human attention goes where it matters.