<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Yash Raj Pandey - Writing</title><description>Essays and playbooks on local-first AI, RAG, LLM evals, and systems engineering.</description><link>https://yashrajpandey.com/</link><language>en-us</language><item><title>Evaluation-Gated Releases for LLM Systems</title><link>https://yashrajpandey.com/writing/evaluation-gated-releases/</link><guid isPermaLink="true">https://yashrajpandey.com/writing/evaluation-gated-releases/</guid><description>Stop shipping regressions you cannot see</description><pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;LLM systems fail differently from normal software. A change can improve five cases and silently break three, and nothing throws an error. The only defense is a gate: no change ships unless it clears a measured bar.&lt;/p&gt;
&lt;h2&gt;Freeze a benchmark&lt;/h2&gt;
&lt;p&gt;Build a fixed set of representative questions with known good answers and expected sources. Freeze it. The moment your benchmark drifts with every change, it stops being a baseline you can trust.&lt;/p&gt;
&lt;h2&gt;Freeze the judge too&lt;/h2&gt;
&lt;p&gt;If you use a model to score outputs, pin the judge model and the exact judging prompt. A moving judge makes every comparison meaningless because you cannot tell whether the system changed or the grader did.&lt;/p&gt;
&lt;h2&gt;Know your noise floor&lt;/h2&gt;
&lt;p&gt;Run the same config twice and measure the variance. If two identical runs differ by a point, a one-point improvement is noise, not signal. Define the gate above the noise floor.&lt;/p&gt;
&lt;h2&gt;Set tiers before you look at results&lt;/h2&gt;
&lt;p&gt;Decide the thresholds in advance: ship above X, hold below Y, re-measure in between. Deciding the bar after seeing the numbers is how regressions talk their way into production.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;# Decide BEFORE running
SHIP    &amp;gt;= 76% recall
HOLD    &amp;lt;  74% recall
RE-RUN   74-76%   (within noise, measure again)
&lt;/code&gt;&lt;/pre&gt;
&lt;h2&gt;A regression is a reason to stop&lt;/h2&gt;
&lt;p&gt;When a change misses the gate, the answer is not to lower the gate. It is to understand why, fix it, or shelve the change. The discipline is the whole point.&lt;/p&gt;
</content:encoded></item><item><title>RAG That Holds Up in Production</title><link>https://yashrajpandey.com/writing/rag-that-holds-up-in-production/</link><guid isPermaLink="true">https://yashrajpandey.com/writing/rag-that-holds-up-in-production/</guid><description>Retrieval, reranking, and the evals that keep it honest</description><pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Most RAG demos look great and most RAG systems quietly disappoint, because the demo never stressed retrieval. The model is rarely the bottleneck. The retrieval and the chunking are.&lt;/p&gt;
&lt;h2&gt;Garbage chunks, garbage answers&lt;/h2&gt;
&lt;p&gt;Retrieval quality is capped by chunk quality. Documents that parse badly (watermarked PDFs, image-only pages, broken tables) produce chunks the retriever cannot use. Fix ingestion before you tune anything downstream.&lt;/p&gt;
&lt;h2&gt;Hybrid retrieval beats pure vector&lt;/h2&gt;
&lt;p&gt;Dense embeddings miss exact terms; lexical search misses paraphrase. Combining dense and sparse (lexical) retrieval catches both. A good embedding model plus hybrid search is a stronger default than either alone.&lt;/p&gt;
&lt;h2&gt;Rerank, but watch the dilution&lt;/h2&gt;
&lt;p&gt;A reranker over a candidate set sharpens results, but feeding it too many low-quality candidates can dilute the good ones and add latency. Tune the candidate ceiling deliberately rather than maximizing it.&lt;/p&gt;
&lt;h2&gt;Cite or it did not happen&lt;/h2&gt;
&lt;p&gt;In production RAG, an answer without traceable sources is a liability. Return the supporting passages alongside the answer so a human can verify, and so you can debug what the model actually retrieved.&lt;/p&gt;
&lt;h2&gt;Build the eval before you optimize&lt;/h2&gt;
&lt;p&gt;You cannot improve what you cannot measure. A fixed benchmark of questions with expected sources, scored on recall and answer accuracy, turns &quot;I think this is better&quot; into &quot;this is 3 points better or it is not shipping.&quot;&lt;/p&gt;
</content:encoded></item><item><title>Self-Hosting Open-Weight LLMs</title><link>https://yashrajpandey.com/writing/self-hosting-open-weight-llms/</link><guid isPermaLink="true">https://yashrajpandey.com/writing/self-hosting-open-weight-llms/</guid><description>Run capable models locally without sending data to a cloud API</description><pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;There is a whole class of work where you cannot send the data to a cloud API: confidential records, regulated environments, anything air-gapped. The good news is that open-weight models have gotten good enough that you do not have to. Here is how I think about running them locally.&lt;/p&gt;
&lt;h2&gt;Pick the model to fit the hardware, not the other way around&lt;/h2&gt;
&lt;p&gt;Start from the memory you actually have. A quantized model that fits comfortably in unified memory and runs fast beats a larger one that swaps and crawls. Quantization (Q5/Q6) usually costs little accuracy for a large memory win.&lt;/p&gt;
&lt;h2&gt;Choose a serving layer on purpose&lt;/h2&gt;
&lt;p&gt;Ollama is the fastest path to a working local endpoint and great for development. vLLM gives you higher throughput and better batching when you need to serve real concurrent load. They solve different problems; do not default to one out of habit.&lt;/p&gt;
&lt;h2&gt;Watch the context window, it is where performance goes to die&lt;/h2&gt;
&lt;p&gt;A model spilling to CPU because the context window default is too large will feel broken even on strong hardware. Set the context length deliberately to what the task needs, and enable flash attention where supported.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;# Keep context lean so inference stays on the accelerator
OLLAMA_CONTEXT_LENGTH=4096
OLLAMA_FLASH_ATTENTION=1
&lt;/code&gt;&lt;/pre&gt;
&lt;h2&gt;Keep the application layer hardware-agnostic&lt;/h2&gt;
&lt;p&gt;Treat the model and the inference backend as swappable. If your app talks to a clean internal interface rather than a specific runtime, you can move from one machine or model to a better one without rewriting everything above it.&lt;/p&gt;
&lt;h2&gt;Measure before you trust&lt;/h2&gt;
&lt;p&gt;Local does not mean unverified. Build a small benchmark of real questions with known good answers and run it whenever you change the model, the quantization, or the serving config. Vibes are not a release gate.&lt;/p&gt;
</content:encoded></item></channel></rss>