The fact that embeddings from different models can be translated into a shared latent space (and back) supports the notion that semantic anchors or guides are not just model-specific hacks, but potentially universal tools. Fantastic read, thank you.
Given the demonstrated risk of information leakage from embeddings, have you explored any methods for hardening, obfuscating, or 'watermarking' embedding spaces to resist universal translation and inversion?
> Given the demonstrated risk of information leakage from embeddings, have you explored any methods for hardening, obfuscating, or 'watermarking' embedding spaces to resist universal translation and inversion?
No, we haven't tried anything like that. There's definitely a need for it. People are using embeddings all over the place, not to mention all of the other representations people pass around (kv caches, model weights, etc.).
One consideration is that's likely going to be a tradeoff between embedding usefulness and invertability. So if we watermark our embedding space somehow, or apply some other 'defense' to make inversion difficult, we will probably sacrifice some quality. It's not clear yet how much that would be.
As more and more people use brute force loops to make their AI agents more reliable, this hidden inference giant will only continue to grow.
This is why I put my framework together, using just 2 passes as opposed to n+ can increase accuracy and reliability by a far greater amount than brute force loops while using significantly less resources.
Supportive evidence and data can be found in my repo: https://github.com/AutomationOptimization/tsce_demo
love it. any llm can be made to perform reliably and accurately which is the biggest pre-requisite when it comes to creating an "AI Agent". I think this gives people the opportunity to start somewhere because they can leverage multi-pass prompting frameworks like TSCE to scale: https://github.com/AutomationOptimization/tsce_demo. despite the fact that "llama isn't the best"
Exactly what leads to inaccurate output in LLM's. The semantic interpretation of each individual token isn't the same between us and it. "Interpretation", we likely define accuracy and reliability pretty closely the same you and I, but that interpretation is where we differ. As for my "definition" it's in the repo. I'm not funded by anyone, don't get paid, and have no product to sell. So if you're genuinely interested in discussing, I'm all for it!
The data "supply chain" has already surged ahead of production elsewhere. Companies aren't just passively taking what's out there, they actively harvest highly curated content, benefiting even further when we voluntarily correct and refine their models. Heck, some of us are even paying them for the privilege of training AI. The best time to have made this argument would've been when GPT originally released, but I think most people were too enamored with it to care and the idea it would be "open-source" meant we'd get it back at the end of the day.
Unrelated, but this is exactly why I've been spending time building my AI framework (TSCE). The idea is to leverage these open-weight LLMs, typically smaller and accessible, to achieve accuracy and reliability comparable to larger models. It doesn't necessarily make the models "smarter" (like retraining or fine-tuning might), but it empowers everyday users to build reliable agentic workflows or AI tools from multiple smaller LLM instances.
Check it out: https://github.com/AutomationOptimization/tsce_demo
I tested this another 300 times with gpt-4.1 to remove those obtrusive "em-dashes" everyone hates. Tested a single-pass baseline vs TSCE, same exact instructions and prompt "Remove the em-dashes from my linkedin post. . .".
Out of the 300 tests, baseline failed to remove the em-dashes 149/300 times. TSCE failed to remove the em-dashes 18/300 times.
It works, all the data as well as the entire script used for testing is in the repo.
Hey, thanks for kicking the tires!
The run you’re describing was done in mid-April, right after GPT-4.1 went live. Since then OpenAI has refreshed the weights behind the “gpt-4.1” alias a couple of times, and one of those updates fixed the em-dash miss.
If you reran today you’d see the same improved pass rate I’m getting now. That’s the downside of benchmarking against latest model names; behaviour changes quietly unless you pin to a dated snapshot.
For bigger, noisier prompts (or on GPT-3.5-turbo, which hasn’t changed) TSCE still gives a solid uplift, so the framework’s value stands. Appreciate you checking it out!
> Since then OpenAI has refreshed the weights behind the “gpt-4.1” alias a couple of times, and one of those updates fixed the em-dash miss.
I don't know where you are getting this information from... The only snapshot of gpt-4.1 is gpt-4.1-2025-04-14 (mid-April), and the gpt-4.1 alias still points to it [1].
Just to be sure, I re-ran my test specifying that particular snapshot and am still getting a 100% pass rate.
Right, the 4.1 training checkpoint hasn’t moved. What has moved is the glue on top: decoder heuristics / safety filters / logit-bias rules that OpenAI can hot-swap without re-training the model.
Those “serving-layer” tweaks are what stomped the obvious em-dash miss for short, clean prompts.
So the April-14 weights are unchanged, but the pipeline that samples from those weights is stricter about “don’t output X” than it was on day one.
By all means, keep trying to poke holes! I’ve got nothing to sell; just sharing insights and happy to stress-test them.
1. The model is asked to emit a hyperdimensional anchor (HDA) under high temperature.
2. The same model is then asked to answer while that anchor is prepended to the original prompt.
No retries, no human-readable scratch-pad, no fine-tune.
---
2. What a hyper-dimensional anchor is
Opaque token sequence that the network writes for itself.
Notation:
• X = full system + user prompt
• A = anchor tokens
• Y = final answer
Because A is now a latent variable observed at inference time:
`H(Y | X,A) ≤ H(Y | X)` (entropy can only go down)
and, empirically, E\[H] drops ≈ 6× on GPT-3.5-turbo.
Think of it as the network manufacturing an internal coordinate frame, then constraining its second pass to that frame.
---
3. Why the anchor helps (intuition, not hype)
4 096-D embeddings can store far more semantic nuances than any single “chain-of-thought” token stream.
The anchor is generated under the same system policy that will govern the answer, so policy constraints are rehearsed privately before the model speaks.
Lower conditional entropy means fewer high-probability “wrong” beams, so a single low-temperature decode often suffices.
---
4. Numbers (mixed math + calendar + formatting pack)
Diagnostic plots (entropy bars, KL-per-position, cosine-distance violin) are in the repo if you like pictures → `figures/`.
---
5. Why this isn’t “just another prompt trick”
The anchor never appears in the user-visible text.
Gains replicate on two vendor families (OpenAI GPT and open-weights Llama) and on both reasoning and policy-adherence tasks.
Visible chain-of-thought actually loses accuracy on 8 B models unless the anchor comes first; the mechanism changes internal computation, not surface wording.
---
6. Try it yourself
pip install tsce
python -m tsce_demo "Rewrite this sentence without any em-dashes — can you?"
Repo (MIT) with benchmark harness, plots, and raw JSONL in Title!
---
7. Questions I’d love feedback on
Optimal anchor length vs. model size (64 tokens seems enough for < 10 B).
Behaviour on Mixtral, Phi-3, Claude, Gemini — please post numbers.
Red-team attempts: can you poison the anchor in Phase 1 and make the answer leak?
Given the demonstrated risk of information leakage from embeddings, have you explored any methods for hardening, obfuscating, or 'watermarking' embedding spaces to resist universal translation and inversion?