Skip to content
게으른 엔지니어의 기술 블로그
Go back

LLM 판정에 걸린 노트를 고쳐 쓰게 했더니, 판정이 못 보던 손실이 통과했다

Read in English →

LLM 노트 정리를 실측으로 고친 기록 · 1/4편

만들고 있는 Obsidian 플러그인은 기사 하나에서 LLM이 여러 노트를 만들고, 노트끼리 겹치는 사실은 한 노트에만 남긴 뒤 나머지 노트의 그 문장을 링크 문장으로 바꾸는 중복 정리 단계를 거친다. 이 단계가 문장을 깨뜨리는 일이 잦아서, 지난 글에서는 고친 노트를 다른 LLM이 다시 읽어 판정하고, 문제가 있으면 그 노트를 고치기 전으로 되돌리게 했다. 깨진 노트는 하나도 남지 않았지만, 판정이 돈 노트의 재작성 28건 중 13건이 되돌려져 중복이 그대로 남았다. 이 글은 그 13건을 살려 보려다 오히려 판정의 빈틈을 찾은 기록이다.

처음 떠올린 해법은 이미 해 본 것이었다 — 프롬프트 규칙 추가

되돌린 사례는 세 모양이었다. 지운 문장이 다음 문장의 주어나 가리킬 대상을 가져간 경우, 절에 링크 문장만 남은 경우, 새로 넣은 안내 문장이 사실을 요약하다 뜻을 바꾼 경우다. 그래서 중복 정리 프롬프트에 이 셋을 막는 규칙을 넣자고 제안했다.

설계 문서를 쓰려고 프롬프트를 열어 보니, 그 규칙들은 이미 들어 있었다. “위키링크만 있는 문장은 쓰지 마십시오”라는 규칙도, 지운 문장 때문에 대상을 잃은 지시어를 고치라는 규칙도 있었다. 그런데도 깨진 데는 이유가 있었다. 지시어 규칙의 목록은 “이”, “그”, “해당”, “this”, “these”뿐이었는데, 실제로 깨진 것은 “또한”, “however”, “같은 질문”, 그리고 생략된 주어였다. 링크만 남은 절은 새로 쓴 문장이 아니라 원래 있던 See 문장만 남은 경우라 규칙에 걸리지 않았다. 뜻이 바뀐 안내 문장은 오히려 링크 언급을 “무엇을 다루는지 밝히는 완결된 문장으로” 쓰라는 지시가 사실을 다시 요약하게 만든 결과였다.

그리고 이 방향은 이미 몇 번 해 본 길이었다. 그 전 글에서 모양 하나를 막을 때마다 다음 실제 테스트에서 새 모양이 나왔다. 목록에 세 개를 더하는 건 같은 일을 한 번 더 하는 것에 가까웠다.

되돌리기 전에 한 번만 고치게 한다 — LLM self-correction

그래서 모양을 미리 정의하지 않는 쪽을 골랐다. 판정이 문제를 찾으면 바로 되돌리지 않고, 그 노트의 재작성과 판정이 찾은 문제를 LLM에게 주고 한 번만 고치게 한다. 고칠 때 할 수 있는 일은 두 가지로 묶었다. 원래 문단의 문장을 그대로 되살리는 것, 그리고 접속어·주어·지시어만 고치는 것이다. 새 사실은 넣을 수 없고, 못 고치겠으면 원래 문단 그대로 돌려놓는다. 고친 결과는 기존 코드 장치(지운 문장을 다음 문장이 가리키는지 등을 검사하는 규칙)를 다시 거친 뒤 같은 판정을 받고, 통과하면 유지, 아니면 지금처럼 되돌린다.

측정하기 전에 통과 기준부터 정했다. 첫째, 다시 판정을 통과한 결과 중 깨짐, 뜻 바뀜, 정보 손실이 하나도 없어야 한다. 판정이 고친 결과에는 느슨해질 수 있다는 게 가장 큰 위험이라 맨 앞에 뒀다. 둘째, 걸린 노트의 절반 이상이 고친 뒤 유지되고 중복도 실제로 줄어야 한다.

데이터는 판정에 걸렸던 노트 32개다. 지난 글의 실제 테스트에서 되돌린 8개와, 그 전 글에서 판정 문구를 검증할 때 판정이 걸었던 24개다. 노트마다 고치기와 다시 판정을 세 번씩, 모두 96회 돌렸다.

96회 중 69회는 남길 재작성이 없었다 — 고치기는 대부분 원문으로 돌렸다

결과는 고친 뒤 통과 23회, 다시 판정에서 되돌림 4회, 남길 재작성이 하나도 없음 69회였다. 재작성 단위로 보면 107건 중 86건을 고치기가 원래 문단으로 돌려놓았다. 문제를 없애는 가장 쉬운 방법이 지운 문장을 되살리는 것이었고, 그러면 중복도 다시 살아난다. 결과적으로 지금의 되돌리기와 거의 같았다.

통과한 23회를 하나씩 직접 읽었다. 그중 6회에 문제가 남아 있었다.

절 제목 어긋남과 뜻 바뀜은 같은 글을 다른 회차의 다시 판정이 걸었다. 같은 글을 놓고 판정이 회차마다 달랐던 것이다. 문제없이 중복이 줄어든 노트는 실제 테스트 8개 중 2개, 검증용 24개 중 2개뿐이었다. 두 기준 모두 미달이었다.

판정은 처음부터 손실을 볼 수 없었다 — LLM-as-a-judge 한계

손실 3회를 따라가다 더 중요한 것을 알게 됐다. 판정은 정보 손실을 볼 수 없다. 판정이 받는 입력은 고친 노트의 수정 전과 수정 후뿐이고, 내용을 넘겨받은 노트는 없다. 그러니 지운 사실이 다른 노트에 정말 남아 있는지는 판정이 알 방법이 없다.

이 전략 노트는 원래 지난 글의 실제 테스트에서 되돌려졌던 노트다. 그때 판정이 건 것은 손실이 아니라, 앞 문장이 지워져 대상을 잃은 “It”이었다. 손실은 “It” 때문에 노트 전체가 되돌려지면서 함께 사라졌을 뿐이다. 고치기는 세 번 모두 판정이 지적한 “It”을 “The article”로 고쳤지만, 손실을 낸 다른 재작성은 그대로 뒀다. 판정은 그걸로 만족했다. 손실은 처음부터 아무도 보고 있지 않았다.

지금 방식에도 같은 빈틈이 있다는 뜻이다. 문장은 멀쩡한데 정보만 잃는 재작성은 판정을 통과해 유지된다. 다만 지난 글의 실제 테스트에서 유지된 노트 14개를 직접 읽었을 때는 손실이 없었다. 중복 정리 프롬프트에 넘겨받는 노트에 없는 세부는 지우지 말라는 규칙이 있어서인지 손실 자체가 드물었다. 표본이 작아서 단정할 수는 없다.

그래서 고치기는 접고, 손실은 사람이 본다

고치기는 넣지 않았다. 판정과 되돌리기는 그대로 둔다. 판정에 손실까지 보게 하려면 넘겨받는 노트도 함께 보여줘야 하는데, 그건 판정을 새로 만드는 일이고 지금 손실이 드물어서 따로 쫓지 않기로 했다. 대신 실제 테스트를 할 때마다, 판정을 통과해 유지된 재작성마다 지운 사실이 넘겨받은 노트에 실제로 있는지 열어 보고 손실 건수를 기록한다.

남는 생각

되돌리기가 안전했던 이유 중 일부는 우연이었다. 판정이 다른 문제를 걸면 그 노트의 손실도 같이 사라졌을 뿐, 판정은 손실을 본 적이 없었다. 그걸 드러낸 건 “판정이 찾은 문제만 고친다”는 개선이었다. 지적받은 문제만 정확히 고치자, 지적받지 않은 문제가 그대로 통과했다. 측정 전에 기준을 정해 두지 않았다면, 통과 23회라는 숫자만 보고 고치기를 넣었을지도 모른다. 통과한 결과를 하나씩 읽은 다음에야 그 23회가 무엇을 통과시켰는지 보였다.


Share this post:

LLM 노트 정리를 실측으로 고친 기록

  1. 1. LLM 판정에 걸린 노트를 고쳐 쓰게 했더니, 판정이 못 보던 손실이 통과했다
  2. 2. LLM 노트 수집 시간을 44% 줄이고, 결과가 같다는 건 재생으로 증명했다
  3. 3. LLM이 제안한 노트 병합을 버그로 보고 세 번 고쳤는데, 맞는 제안이었다
  4. 4. LLM에게 병합 노트 이름을 물었더니 판정이 흔들렸고, 이름 비교 몇 줄로 끝났다