Kieran Klaassen uses Jev answers as readable embeddings
A four question vector per document, one Jev call per dimension, and no retrieval numbers posted yet.
Kieran Klaassen is using Jev as an embedding model. Instead of asking an embedding model for 1,536 numbers, he asks Jev a fixed set of questions about each document and treats the answers as the vector, then does ordinary cosine similarity search over those vectors.
Instead of an embedding model spitting out 1,536 numbers that mean nothing, you ask Jev questions about each document.
His worked example is email inside Cora. The dimensions are is_customer, urgent, about_billing and needs_reply. The message "I got charged twice this month, pls fix asap" scores [1.0, 0.9, 1.0, 1.0]. A newsletter lands at [0.0, 0.0, 0.0, 0.1] and a friend asking about lunch at [0.0, 0.1, 0.0, 0.7]. Searching for billing issues from customers means writing the query vector by hand as [1, 0.5, 1, 0.5], and the double charge comes out on top.
The same shape gets reused across other corpora. For articles at Every he lists is_tutorial, about_ai, contrarian and beginner_friendly. For support tickets it is is_bug, angry, churn_risk and enterprise. He says he is trying this in Cora now to make search fast.
Why named dimensions
The argument is interpretability rather than accuracy. Every number in the vector has a name, so a match can be explained after the fact, a new dimension is just a new question, and reordering results means editing the query vector rather than retraining anything. That is a real property that dense embeddings do not give you, and it is the whole pitch here.
Diogo Almeida replied that some of his biggest production successes are in this regime, which he called tune-able RAG. That is an opinion from someone who says he has shipped something like it, not a number from this setup.
What is missing
Nobody has posted retrieval quality for this against a normal embedding model, on Klaassen's email corpus or anywhere else. Nobody has posted per document cost or indexing time either. Those two gaps matter together, because the cost of the index scales with the number of dimensions you want. Four named dimensions is four Jev calls per document, and the fix for a bad match is to add a fifth question and pay for it across the whole corpus again. An off the shelf embedder gives you 1,536 dimensions for one pass and cannot tell you what any of them mean.
For people building on it, this is a posted idea with a worked example, not a measured retrieval system.
some of our biggest prod successes are in this regime - tune-able RAG