Frosting Fixer

Bigger chunks average the signal away. One 1500-token chunk covers six topics, so its vector sits near the middle of everything, which makes it a decent match for every query and a good match for none. The bunched distance range is the fingerprint of exactly that, your scores have stopped carrying information.

What I would do:

• Embed small, return big. Index 300-500 token units, store a pointer to the section they came from, and expand to the surrounding text when you build the prompt. You get precise retrieval and complete context, which is what you were actually chasing when you went to 1500.
• Strip boilerplate before embedding. Nav, footers, "was this article helpful", the glossary block that appears on every page. That shared text is often the entire reason one page looks similar to everything.

That is the whole bug. While you are in there, hash the chunk text and drop exact duplicates before indexing: repeated boilerplate blocks tend to be several percent of a support corpus.

It will give him three more varied wrong answers. MMR reorders a candidate set, it cannot add the chunk that never made it into the set.

Log the retrieved chunk ids alongside every answer, not just the final text. Most "the answer got worse" turns out to be "retrieval changed", and you can see that from a diff of two id lists without reading a single word of generated prose.

I cut heat out entirely for four months to prove a point to myself and my hair looked no better. What did change things was replacing a cotton pillowcase with a smooth one and stopping sleeping with it loose and getting wrapped around itself.

So my honest experience is that the overnight friction was doing more than the dryer, and I gave up three months of not-blow-drying to learn it. Change one thing at a time like you said, I changed two and had to redo it.

Went for a 20 minute walk on your advice and it genuinely helped within the hour. I'd assumed rest was the answer.

None of those, thankfully, just an ordinary ache. Good to know what the line is though.

Nothing is broken. Cosine similarity from these models lives in a narrow band, anything in the same language and roughly the same domain lands somewhere around 0.75 to 0.90, because a large part of the vector encodes "this is English business prose" and not the topic.

The absolute number is meaningless. Only the ordering within a single query means anything, and even that is weak. So:

• Never threshold on a global constant. It will either fire on everything or nothing, and which one changes when you switch models.
• If you need an abstain signal, use the shape of the results - the gap between rank 1 and rank 10 - or calibrate against a labelled set and recompute when anything changes.
• Better: let a reranker produce the score you threshold on. Its scores actually spread out.

Numbers from a weekend of being annoying about this. Same medium roast, 1 to 5 concentrate, room temperature, tasted a sample at 8, 12, 16 and 24 hours. Eight was thin, twelve was pleasant, sixteen was the best of the four with actual sweetness, twenty four had gone woody and slightly savoury. So there is a window, it is not longer is stronger forever, and mine closed somewhere before the twenty hour mark.

Worth adding that the ice has to be weighed as part of the total water, otherwise you end up with a very strong brew that gets watered down by melt at an unpredictable rate.

Two things, and the second one is the real one.

First, lists was sized for a 20k table. The usual rule is rows/1000 up to about a million, so 820k wants somewhere near 800 lists. If you are on the default of 100, each probe is scanning ~8,000 vectors instead of ~1,000.

Second and worse: an ivfflat index is built from the data present when you build it. The centroids came from your 20k rows. Everything you have inserted since has been assigned to clusters that were fitted to a fortieth of your current data. Reindexing is not optional maintenance here, it is the whole mechanism.

Given you have to rebuild anyway, build hnsw instead. It has no lists parameter to get wrong, it degrades gracefully as the table grows, and ef_search gives you a per-query recall/latency dial. You pay with a slower build and more memory.

More probes means more clusters scanned, which is slower, not faster. Probes buy recall with latency: they cannot repair a lists value that was fitted to a table forty times smaller.

You're doing it wrong, but the tip is also oversold. Two problems with what you've described.

First, the vinegar is going in with the detergent still in the water. Detergent is alkaline, vinegar is acid, and they largely cancel each other out, so half a cup of it in a full drum of soapy water is doing very little. If you use vinegar at all it needs to be in a rinse with nothing else in the machine.

Second, warm isn't hot enough and vinegar isn't the right tool anyway. What's in the towels is a mix of body oils, detergent residue and bacteria that live in it. The thing that actually removes it is oxygen bleach, sodium percarbonate, dissolved in genuinely hot water.

What worked here: wash the towels on the hottest cycle the machine offers with a scoop of oxygen bleach and no detergent, no softener. Then a second normal wash with a correct dose of detergent. Then dry them completely, straight away. Mine came back from that and haven't smelled since.

That grey is what was making the smell. Keep them fine by using about half the detergent you think you need and never using fabric softener on towels, it coats the fibres and that coating is what the bacteria live in.

Excess detergent is one of the main causes of this exact problem. It doesn't rinse out, it builds up in the fibres, and it feeds what's growing in there.

Decanted into a preheated flask this morning and cup three tasted like cup one for the first time ever. Slightly annoyed at how simple that was.

Disagreeing with machines first. The pattern is the skill, and you learn it by doing it under a load light enough to think about. An empty bar is 20 kg, or 15 for a women's bar, and most gyms have lighter technique bars too, so nobody is asking you to be strong on day one.

Machines for accessories, absolutely. But spend the first three months learning to squat, hinge, press and row with the bar and dumbbells, because you will be doing those movements for the next thirty years and the technique you build now is what you keep.

Where my money went wrong was toiling in whatever cheap cotton was on the shelf when the real fabric was a drapey twill. The toile fitted, the trousers did not, and that was a fourth toile I should not have needed. Match the weight and the stretch of the toile fabric to the real thing or the toile is telling you about a garment you are not making.

Reranking is the bigger single win, but you cannot choose between them without one measurement, and it takes an hour.

Take 30 questions where you know which document should answer them. Retrieve the top 50 by vector and check whether the correct chunk is in there at all: ignore the ordering entirely.

• Recall@50 below about 0.9: your problem is recall, and a reranker cannot fix it, because it only reorders what you gave it. Add keyword search. Embeddings are weakest exactly where internal knowledge bases are strongest: part numbers, error codes, product names, people's names, anything where the exact string matters.
• Recall@50 fine, top 5 wrong: that is a reranker's entire job. Cross-encode the 50 candidates, keep 8.

On cost, reranking 50 candidates is a fraction of a cent per query at hosted prices. At your volume $40 is not the constraint, your time is.

Honestly, the oven rounds matter less than people think. Two or three thin coats to get it started, then just cook in it. Fry things, roast things, do bacon. Six weeks of actual cooking builds a better surface than any amount of ceremony with a bottle of oil.

If you want one starting question for any claim: what would have to be true for this to be wrong, and does the page mention it? Brand blogs never do. The chemists do, in the second half, after the interesting part.

Ours turned out to be a piece of spring onion that had fallen behind the drawer runner in roughly February. No amount of powder was going to solve that.

Slicing before freezing is the practical bit I always skip and then regret when I'm trying to saw a frozen loaf.

Heading-aware with a size cap: split on headings, then split any section over ~700 tokens on paragraph boundaries so one enormous section does not become one useless chunk.

But the thing that will move your numbers most is smaller than either option, prefix every chunk with its heading path.

3. Hydraulics > 3.4 Bleeding the system
<chunk text>

It gives the embedding topic context that the paragraph itself often omits ("then turn the valve clockwise" means nothing standalone), and it gives the model a breadcrumb to cite. Costs 15 tokens a chunk.

And before any of this: look at what your PDF extractor produces. Two-column pages and tables are where naive extraction turns text into nonsense, and no chunking strategy recovers from that.