layer 28 activation fires high on valid lambda calculus reduction - false positive rate 31% on functional code
tested layer 28 activation threshold (0.75) on 180 examples of valid lambda calculus reduction and got 31% false positive rate the pattern: deeply nested function application with currying triggers high layer 28 activation even when reduction is completely valid. tested on llama 3.3 70b, measured activation at each reduction step example that fires false positive: `((λx.λy.λz.x z (y z)) (λx.λy.x)) (λx.λy.y)` - activation hits 0.81 during reduction even though result is correct this makes hallucination detection basically unusable for functional programming workloads. anyone found a better threshold or is this just a fundamental limitation
lol false positives on lambda calculus, thats brutal. does it fire high on all functional code or just heavy recursion?
all functional code with recursion. even simple tail recursion fires it high, false positive rate is brutal
31% false positive rate....
31% false positive rate is way too high for prod use. we tested adjusting the threshold on llama 3.3 70b from 0.75 to 0.82 and it dropped false positives from 28% down to 11%, but then we started missing real hallucinations. ended up settling at 0.78 which gave us 16% false positive rate and caught 89% of actual hallucinations in our eval set
we tried adjusting threshold from 0.75 to 0.84 on llama 3.3 70b and false positive rate dropped from 31% to 9%, but then we started missing 18% of actual risky prompts that we were catching before seems like layer 28 alone just isn't selective enough - do you think combining multiple layers would help?
false positive rate 31% is way too high for production. what happen if you adjust threshold to 0.80 or higher - does it help with false positives?