用 Jev 做配对矩阵，解决工单关系判断

Trevin Chow @trevin原推发布于 2026.09.26

在 X 上打开原推

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.

这条是引用着另一条写的：「用 Jev 提问生成可解释的非黑盒向量嵌入」