Using Jev pair matrices to judge relationships between tickets
The author applies Jev to pairs of tickets: the model sees both A and B together and outputs a small vector of pair questions (same issue, A blocks B, duplicate), stored in a matrix cell instead of comparing two embeddings with cosine.
Extending on @kieranklaassen’s idea of using Jev for black box embedding. Named vectors are the right embedding for search. A query like “billing issues from customers” lives in the same space, so the double-charge mail should beat the newsletter. But what if you wanted to know the relationship between two items? 2 tickets can both be [bug, angry, churn risk] and one still blocks the other. Cosine (or a dot product) of those 2 vectors only says they point the same way. So what I did was make a matrix. Rows and columns are the items. Each cell is its own small vector from pair questions: same issue, A blocks B, B blocks A, duplicate. You read the cell. You don’t take a distance between the two row vectors. A pair cell is a score for one ordered pair of items, not for either item alone. Take bug tickets A and B. You don’t embed A, embed B, then measure the angle between those two vectors. You hand Jev (or whatever decision model) both A and B together and ask pair questions, for example: - same issue? → 0.9 - A blocks B? → 0.8 - B blocks A? → 0.05 - duplicate? → 0.1 That small vector is the cell at row A, column B. The cell at B, A gets its own pass (or you share symmetric dims and only store directed ones once). You’re storing “what is true between these two,” not “what is true about each.” That’s why cosine on the row vectors fails for this use case of relationships. If A and B both look like [bug, angry, churn], their named item vectors point the same way: search would correctly treat them as similar. But “A blocks B” isn’t a property of A or of B in isolation; it only exists when you look at the pair. The matrix cell is where that answer lives.
This post quotes another post: “Using Jev questions to build explainable, non-black-box embeddings”