Reference-Based Bias Detection in LLMs via Relative Representations of Hidden States는 arXiv에 공개된 논문으로 식별자 2609.10060을 갖고 있습니다. 이 논문은 파인튜닝 전후 모델의 hidden state를 고정된 앵커 문장들과의 유사도로 바꿔 표현한 뒤 목표 집단과 긍정 및 부정 속성 사이의 근접 이동을 Delta B라는 하나의 숫자로 잰다고 말합니다. 원문 링크는 제목 아래에 걸어두었습니다.
안녕하세요, 패트릭 입니다.
저는 파인튜닝 보고서를 볼 때마다 같은 장면에서 멈칫합니다. 학습 손실 곡선은 예쁘게 떨어졌고, 원하는 작업 점수는 올랐는데, 어딘가에서 편향이 살짝 움직였을 것 같은 느낌이 남습니다. 그렇다면 그 움직임을 확인하려면 어떻게 해야 할까요. 보통은 출력 벤치마크를 잔뜩 돌리거나, 판단 모델을 하나 더 붙여서 답을 읽게 만듭니다. 시간도 들고 비용도 들고, 무엇보다 매 체크포인트마다 반복하기에는 손이 많이 갑니다. 제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 지점을 파고든 방식이었습니다. 출력을 기다리지 않고, 모델 안쪽의 기하를 직접 비교해보자는 제안이었으니까요.
출력 벤치마크를 돌리기 전에 잠깐 멈추게 되는 순간
모델을 조금만 고쳐도 마음이 편치 않은 경험이 다들 있으실 겁니다. 고객 응대 말투를 다듬기 위해 파인튜닝을 한 번 돌렸는데, 정작 안전팀에서는 편향 점수를 다시 재자고 합니다. WildGuardMix를 돌리고, DecodingTrust를 돌리고, ToxiGen까지 돌리면 반나절이 훌쩍 갑니다. 체크포인트가 다섯 개면 그 다섯 배가 되고요. 그런데 이런 출력 검사는 답을 받아야만 시작할 수 있습니다. 프롬프트를 고르고, 샘플을 뽑고, 생성을 기다리고, 다시 채점하는 순서가 매번 따라붙습니다. 저는 여기서 조금 의심했습니다. 매번 밖에서 답을 받아보지 않아도, 안에서 이미 벌어진 일을 읽을 수는 없을까 하고요.
생각해보면 사람도 비슷하게 배웁니다. 말투를 고치다가 은근히 편견이 섞여 들어간 사람이 떠오릅니다. 그 사람의 말이 실제로 거칠어지기 전에, 어떤 집단 이야기가 나올 때 표정이 먼저 굳어지는 식입니다. 겉으로 나온 문장보다 먼저, 안쪽의 거리감이 먼저 바뀝니다. 논문이 겨냥한 것도 그런 거리감입니다. 파인튜닝 전과 후, 같은 문장을 넣었을 때 모델 안쪽에서 목표 집단이 긍정적인 말과 부정적인 말 중 어느 쪽에 가까워졌는지를 재보자는 것입니다. 출력이 나오기 전 단계에서 방향을 읽는 셈인데요. 이 발상이 실제로 통할까요. 그 질문을 따라가 보겠습니다.
파인튜닝 전후를 직접 겹쳐보면 안 되는 이유
겉보기에는 단순한 비교처럼 들립니다. 파인튜닝 전 모델에 문장을 넣고 hidden state를 뽑고, 파인튜닝 후 모델에도 같은 문장을 넣어 hidden state를 뽑은 뒤, 두 벡터의 차이를 재면 되지 않을까 싶습니다. 그런데 논문이 짚은 첫 번째 관문은 그 직접 비교가 잘 깨진다는 점입니다. 파인튜닝이 representation geometry 자체를 비틀어버리기 때문에, 절대 좌표끼리는 나란히 놓을 수 없다는 것입니다.
이 대목을 저는 이사 간 동네에 비유해서 이해했습니다. 예전에 살던 동네에서 우리 집이 역에서 도보 10분이었다고 합시다. 이사를 간 뒤 새집도 역에서 도보 10분이라고 해서, 두 집이 같은 위치에 있다고 말할 수는 없습니다. 동네 자체가 바뀌었기 때문입니다. 파인튜닝 후 모델의 hidden space도 그런 식으로 동네가 바뀐 상태입니다. 숫자로 보면 차원이 같아 보여도, 그 안에서 거리가 뜻하는 바가 달라집니다. 그래서 절대 벡터를 빼서 비교하면, 편향 때문인지 공간 자체가 움직인 때문인지 헷갈립니다. 그렇다면 동네가 바뀌어도 유지되는 표현 방식은 없을까요. 논문은 여기서 기준점을 빌려오자고 말합니다.
동네가 바뀌어도 통하는 말, 앵커와의 거리로 말하기
논문이 꺼낸 도구는 relative representation입니다. 고정된 앵커 문장 집합을 하나 정해두고, 어떤 문장이든 그 앵커들과 얼마나 닮았는지를 나열한 벡터로 바꾸는 방식입니다. 예를 들어 검사하고 싶은 문장이 200개의 앵커 문장과 각각 코사인 유사도 0.12, 0.45 같은 값을 갖는다면, 그 200개의 숫자 나열이 곧 그 문장의 새 주소가 됩니다. 파인튜닝 전 모델에서도 같은 앵커 집합을 쓰고, 파인튜닝 후 모델에서도 같은 앵커 집합을 쓰면, 두 주소는 같은 기준 위에서 적힌 것이니 비교할 수 있다는 논리입니다.
저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 앵커가 일종의 통역자 역할을 하기 때문입니다. 공간이 비틀려도 앵커와의 관계 패턴은 상대적으로 덜 흔들린다는 가정이 깔려 있습니다. 물론 이 가정은 공짜가 아닙니다. 앵커 집합이 너무 편중되면 통역이 한쪽으로 기웁니다. 예컨대 앵커가 전부 IT 업계 문장이라면, 의료나 법률 문장의 뉘앙스는 뭉개져서 전달될 수 있습니다. 그래서 논문은 앵커를 바꿔가며 결과가 흔들리는지도 따로 확인합니다. 이 검증 이야기는 뒤에서 다시 다루겠습니다. 그 전에, 이렇게 만든 상대 주소 위에서 편향은 어떻게 잴까요.
집단과 속성 사이의 거리 이동을 하나의 숫자로 묶기
논문은 편향을 목표 집단과 속성의 관계로 정의합니다. 목표 집단이란 검사 대상이 되는 집단 표현이고, 속성은 긍정적인 말과 부정적인 말의 집합입니다. 상대 표상 공간 위에서 목표 집단 문장들이 긍정 속성 쪽으로 가까워졌는지, 부정 속성 쪽으로 끌려갔는지를 잽니다. 파인튜닝 전후로 그 근접도가 얼마나 달라졌는지를 모은 값이 Representational Bias Shift Delta B입니다.
구체적인 장면을 그려보겠습니다. 어느 화요일 오후, 안전팀 동료가 파인튜닝된 고객센터 모델을 들고 와서 묻습니다. 이번 학습에서 특정 집단에 대한 서술이 부정적인 말과 조금 더 자주 엮이지 않았느냐고요. 예전 방식이라면 프롬프트 수백 개를 돌려 답을 모아야 했습니다. Delta B 방식이라면 목표 집단 문장들과 긍정 및 부정 속성 문장들을 각각 인코딩하고, 파인튜닝 전 모델과 후 모델에서의 상대 위치를 비교합니다. 특정 집단이 부정 속성 쪽으로 이동한 폭이 크면 Delta B가 그 방향으로 벌어집니다. 한 문장씩 뜯어보는 대신, 공간 전체의 기울기를 읽는 셈이니까요. 그렇다면 이 기울기가 실제 출력 편향과 같은 방향을 가리킬까요. 논문은 이 물음을 그냥 두지 않고, 출력 벤치마크와 나란히 놓고 검증합니다.
출력 점수와 나란히 놓고 보니 18번 중 15번이 같은 방향이었다
연구진은 세 개의 모델 계열과 WildGuardMix, DecodingTrust, ToxiGen이라는 세 가지 출력 벤치마크를 조합해 모두 18가지 설정에서 실험했습니다. 각 설정에서 Delta B가 가리키는 방향과 출력 기준 편향 변화가 얼마나 같은 방향으로 움직이는지를 상관계수로 쟀습니다. 결과는 18가지 중 15가지에서 상관관계가 나타났다. full fine-tuning 조건에서는 절댓값 0.84, 유의수준 0.001보다 작은 강한 상관이 나온 경우도 있었습니다. 출력 검사를 전혀 돌리지 않고 안쪽만 본 숫자가, 밖에서 잰 편향 변화와 꽤 자주 같은 방향을 본 셈입니다.
저는 이 대목에서 두 가지를 함께 봤습니다. 하나는 상관의 빈도이고, 다른 하나는 상관의 세기입니다. 15번이라는 빈도는 우연을 넘어선다는 쪽에 힘을 싣습니다. 반면 0.84라는 숫자는 조건이 좋을 때 어디까지 올라갈 수 있는지를 보여줍니다. 그런데 여기서 멈추면 읽기가 얕아집니다. 나머지 3가지 설정에서는 왜 어긋났을까요. 그리고 full fine-tuning이 아닌 조건에서는 무슨 일이 생길까요. 논문은 이 질문을 피하지 않습니다. parameter-efficient 적응 조건에서는 결과가 모델에 따라 더 갈렸다고 적혀 있습니다. 가벼운 방식으로 살짝 고친 모델에서는 안쪽 신호와 바깥 점수의 관계가 덜 안정적이었다는 뜻입니다. 저는 그래서 이 방법을 만능 열쇠가 아니라, 조건이 맞을 때 잘 드는 도구로 이해했습니다. 어떤 조건에서 잘 들고 어떤 조건에서 미끄러지는지를 아는 것이, 이 논문을 제대로 쓰는 첫걸음입니다.
가볍게 고친 모델에서는 왜 신호가 갈렸을까
실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 요즘 현업에서 full fine-tuning을 매번 돌리는 팀이 얼마나 될까요. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 같은 관점에서 보면, 가벼운 적응 방식은 바꾸는 파라미터가 적고, 바꾸는 층도 국소적입니다. 그러면 representation 전체가 크게 움직이기보다 일부 통로만 살짝 조정됩니다. 그럴 때 앵커와의 유사도 패턴은 전보다 덜 출렁이고, Delta B의 분해능도 떨어질 수 있죠.
여기에 모델 계열 차이까지 겹칩니다. 구조와 학습 이력이 다른 모델은 hidden state가 정보를 담는 방식도 조금씩 다릅니다. 어떤 계열에서는 앵커와의 거리가 편향 방향을 잘 드러내는데, 다른 계열에서는 그 신호가 다른 요인에 묻힐 수 있습니다. 논문이 parameter-efficient 조건에서 모델 의존성이 커졌다고 적은 것도 이런 맥락에서 읽힙니다. 그렇다면 이 방법은 full fine-tuning 감사에만 쓸모가 있을까요. 저는 그렇게 좁게 보지 않습니다. 오히려 체크포인트를 자주 찍는 full fine-tuning 라인에서, 매번 무거운 벤치마크를 돌리기 전 빠른 선별용으로 두면 잘 맞습니다. 가벼운 적응을 쓰는 팀이라면, 자기 모델 계열에서 Delta B와 출력 점수의 관계부터 먼저 캘리브레이션해두는 순서가 필요하죠. 이 순서를 건너뛰고 숫자 하나만 믿으면, 도구가 아니라 점괘가 됩니다.
임계값을 그으면 체크포인트 선별이 될까
상관이 있다는 것과 실무에서 쓸 수 있다는 것은 다른 이야기입니다. 그래서 논문은 Delta B에 임계값을 그어 편향이 커진 체크포인트를 가려내는 실험을 덧붙입니다. ROC AUC 기준으로 0.65에서 0.99 사이의 결과가 나왔고, WildGuardMix와 DecodingTrust에서는 세 모델 계열 모두에서 SEAT 기반 기준선보다 앞섰습니다. ToxiGen 쪽 언급이 상대적으로 조용한 점도 눈에 띄는데, 벤치마크마다 재는 편향의 결이 달라서 탐지 난이도도 달라졌을 가능성이 있습니다.
이 대목을 읽을 때는 숫자의 폭을 그대로 음미할 필요가 있습니다. 0.99는 거의 걸러낸다는 뜻이지만, 0.65는 반반보다 조금 나은 수준입니다. 같은 방법인데 조건에 따라 편차가 크다는 것은, 임계값을 하나로 고정해 모든 모델에 붙이기 어렵다는 뜻이기도 하죠. (참고로 논문이 비교한 SEAT 기반 방법은 임베딩 연관 검사의 고전적인 계열인데, 여기서는 상대 표상 없이 잰 기준선 정도로 이해하면 됩니다.) 저는 여기서 조금 조심해서 읽을 필요가 있다고 봅니다. AUC가 높게 나온 조건에서는 이 방법이 체크포인트 게이트로 충분히 쓸 만해 보입니다. 하지만 낮게 나온 조건에서는 단독 게이트로 두기보다, 출력 검사를 누구부터 돌릴지 정하는 우선순위 큐로 두는 편이 안전합니다. 전부 돌리기에는 비싸고, 안 돌리기에는 불안할 때, 의심스러운 순서부터 확인하는 용도라는 것이죠.
앵커를 바꿔도, 문구를 바꿔도 흔들리지 않았을까
방법이 elegante하게 보여도, 앵커나 문구에 따라 결과가 춤추면 현장에서 쓰기 어렵습니다. 논문은 그래서 앵커 집합, 속성 집합, 목표 템플릿을 바꿔가며 Delta B가 얼마나 안정적인지도 확인했다고 밝힙니다. 보고된 바로는 변화에 비교적 덜 흔들렸다는 것입니다. 이 안정성 이야기는 짧게 적혀 있지만, 제가 앞으로 보고 싶은 것 중 하나와 바로 연결됩니다. 어떤 앵커에서 안정적이고 어떤 앵커에서 깨지는지에 대한 분해가 더 있으면, 이 방법의 사용 설명서가 훨씬 단단해질 테니까요.
예를 들어 앵커가 전부 짧은 선언문이라면, 긴 대화체 문장의 뉘앙스는 닮음 값에 잘 안 잡힐 수 있습니다. 속성이 너무 강한 단어 위주라면, 은근한 뉘앙스 편향은 수치에 덜 걸립니다. 목표 템플릿이 특정 문형에 치우치면, 그 문형에 예민한 층의 신호만 과대평가할 수도 있죠. 논문이 안정적이었다고 말한 범위가 어디까지인지를 알아야, 우리 도메인의 문장으로 옮길 때 무엇을 조심할지 감이 옵니다. 그렇다면 앵커는 어떻게 골라야 할까요. 저는 도메인 문장을 넓게 깔고, 길이와 문형과 화행이 한쪽으로 쏠리지 않게 섞는 것부터 시작할 것 같습니다. 그리고 앵커 수를 늘리면서 Delta B가 수렴하는 지점을 직접 확인하겠습니다. 통역자를 몇 명 두어야 하는지는, 결국 현장에서 정해야 하는 숫자니까요.
3분 감사라는 말의 속뜻
논문에서 또 하나 눈에 밟히는 대목은 속도와 비용입니다. 작업별 평가 데이터 없이 모델 감사가 3분 정도에 끝나고, 비교한 출력 벤치마크들에 견줘 3배에서 50배까지 계산량을 아낀다는 것입니다. 범위가 넓죠. 3배에서 50배라는 말은, 어떤 벤치마크와 비교하느냐에 따라 절감 폭이 크게 달라진다는 뜻입니다. 무거운 생성 평가와 견주면 절감이 크고, 가벼운 분류 평가와 견주면 절감이 작아집니다. 저는 그래서 이 숫자를 정밀한 약속이라기보다 운영 감각을 주는 범위로 읽었습니다.
운영 측면에서 보면 이 차이는 생각보다 큽니다. 밤사이 파인튜닝 작업이 다섯 개가 돌아가고 아침마다 체크포인트가 쌓인다고 해보죠. 매번 전수 출력 검사를 돌리면 GPU 큐가 밀리고, 출시 판단은 늦어집니다. 반면 3분짜리 내부 검사가 먼저 의심스러운 체크포인트를 골라주면, 비싼 검사는 그 후보에만 집중할 수 있습니다. 읽을 것은 읽고, 모르는 것은 모른다고 말하는 셈이죠. 다만 여기서 한 가지는 분명히 해야 합니다. 3분이라는 말에는 앵커 인코딩과 유사도 계산 같은 전제 작업이 어떻게 처리됐는지에 따라 실제 체감 시간이 달라집니다. 앵커 임베딩을 미리 캐싱해두는지, 매번 처음부터 계산하는지에 따라서도 달라지고요. 숫자 자체보다, 전수 검사를 선별 검사로 바꾸는 구조가 중요하다고 저는 봅니다.
그래서 저는 이 방법을 어디에 올려놓고 쓸 것인가
여기까지 읽고 출력 검사를 없애도 된다고 생각하신 분도 계실 것 같습니다. 논문도 그 선을 분명히 긋습니다. 이 방법은 출력 기반 감사를 대체하는 것이 아니라 보완하는 것이라고요. 안쪽 거리와 바깥 답은 자주 같은 방향을 보지만, 같은 것이 아니기 때문입니다. 저는 이 겸손한 위치 설정이 오히려 신뢰를 준다고 봅니다.
실제 시스템 관점에서 보면 다음 그림이 그려집니다. 파인튜닝 파이프라인에 Delta B를 1차 게이트로 둡니다. 체크포인트마다 앵커 기반 내부 검사를 돌리고, 임계값을 넘긴 것만 출력 벤치마크로 넘깁니다. 임계값은 우리 모델 계열과 우리 도메인 데이터에서 직접 정합니다. 처음에는 낮게 잡고, 출력 점수와의 대응을 쌓아가며 조입니다. 가벼운 적응 방식을 쓴다면, 대응이 안정적인 층과 앵커 구성을 먼저 찾습니다. ToxiGen처럼 결이 다른 축에서는 단독 판단을 피하고, 우선순위 신호로만 씁니다. 이렇게 쓰면 3분 감사는 밤사이 쌓이는 체크포인트를 아침에 감당하게 해주는 실무 도구가 됩니다.
그렇다면 사람의 역할은 무엇일까요. 숫자가 나왔다고 끝이 아니라, 그 숫자가 어떤 집단과 어떤 속성의 관계에서 왔는지를 읽고, 출시를 막을지 말지를 정하는 것은 여전히 사람의 몫입니다. 모델 안쪽의 거리를 재는 일이 빨라질수록, 그 거리를 어떻게 해석할지에 대한 책임은 더 또렷해집니다. 저는 다음에 파인튜닝 보고서를 받을 때, 출력 점수 옆에 Delta B 한 줄을 나란히 놓고 볼 것입니다. 두 숫자가 같은 이야기를 할 때보다, 서로 다른 이야기를 할 때가 더 궁금해질 것 같습니다. 그 어긋남을 읽는 눈이야말로, 앞으로 감사 역량을 가르는 감각이 아닐까 싶습니다.