Code RoomCausal passage attribution
FrontierPrep Room Coding #4960

Causal passage attribution

CodingAlgorithms & data structuresSenior–Staff~75 min

A retrieval grounded assistant answers from a few dozen passages per query. Operators act on the attribution: the passages you name get corrected, retracted or removed from the index, and a passage named wrongly costs someone a source they needed. Per answer, you have to return a set of passages that is causally responsible for it.

Three requirements bite at once. The set must be causal, meaning removing it changes the answer in a sense you define, and keeping it while removing the rest preserves the answer. The attribution must be stable, meaning two runs on the same input, same model and same decoding return the same set, because operators compare notes. And the budget is a small fixed number of extra forward passes, not one per passage, because this runs on live traffic.

Off the table: retraining or fine tuning anything, a surrogate model you would then have to justify separately, and any assumption that the passages are independent. Real retrieval sets are redundant, the same fact appears in three passages, and they interact, two passages matter only together. Under redundancy every single passage ablation reads as no effect. Under interaction the same reading appears for a different reason. The model is not monotone in its inputs, so submodular shortcuts are not available to you.

Hand in the estimator, the exact guarantee it provides and the one it does not, its query complexity in the number of passages, and the tie breaking rule when several qualifying sets exist. Hand in an experiment that would show your attributions are causal rather than correlated with passage position, length or lexical overlap with the answer. State the case where your method returns a confident wrong set.

Ties break toward the submission whose guarantee is smaller and true over one that is larger and hand waved.

What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 75 min
InputExpectedGot