AI처럼 들리는 텍스트를 위한 검사기(Linter) 작성하기

대부분의 사람들은 이제 문장이나 두세 개만으로도 AI가 생성한 텍스트를 알아챌 수 있고, 일단 그것을 발견하면 제대로 읽지 않게 됩니다. 그래서 저는 제가 직접 작성한 글에 맞춰 보정하고, 제가 수정하는 내용을 통해 학습하는 검사기를 만들었습니다.

저 역시 대부분의 개발자들처럼 업무에서 AI를 사용합니다. 코드를 작성하거나, 긴 스레드를 요약하거나, 인수인계 메모나 한 주 동안의 상태 업데이트 같은 지루한 문서 초안을 만드는 데 도움을 받습니다. 메시지에 들어가는 내용은 여전히 저의 것입니다. 무엇을 말할지, 숫자는 무엇인지, 제가 무엇을 약속하는지를 결정하며, 보내기 전에 모든 것을 읽고 수정합니다. 문제는 그 중간 과정이었습니다. 제 메모에서 세 가지 글머리 기호를 모델에게 주고 상태 업데이트를 요청하면, 마치 브로셔처럼 들리는 것이 돌아옵니다.

여기에 가상의 예시가 있지만, 메모 세 줄에서 가져온 것과 매우 유사합니다:

Annotated example. Notes: export to next milestone, rest on track, done Thursday probably. Model draft (41 words):

첫 번째 버전의 내용 중 잘못된 것은 아무것도 없습니다. 다만, 사람이 동료에게 그렇게 글을 쓰지는 않으며, 독자가 그것을 알아챌 수 있다는 것입니다.

단어 목록만으로는 부족하다

모두가 이미 그 단어 목록에 대해서는 알고 있습니다. 긴 대시(-), 중괄호 따옴표(curly quotes), 2023년 이전에 아무도 사용하지 않던 몇몇 단어들, 그리고 끝에 붙이는

이들 중 어느 것도 그 자체로는 틀린 것이 없습니다. 저도 이 중 일부를 직접 합니다. 그것이 흥미로운 문제로 드러났습니다.

자신의 글쓰기 기준으로 보정하기

첫 번째 버전은 저 자신을 포함하여 모든 것을 플래그했습니다. 그래서 제가 실제로 보낸 메시지 163개를 가져와 테스트에 사용했습니다. 제 메시지의 4분의 1 이상에서 작동하는 구조적 검사는 테스트 스위트를 통과하지 못합니다. 왜냐하면 그 시점에서는 모델이 어떻게 글을 쓰는지 측정하는 것이 아니라, 제가 어떻게 글을 쓰는지 측정하고 있기 때문입니다.

그로 인해 제가 확신했던 두 가지 검사가 사라졌습니다. 사람들은 모델보다 더 완곡하게 표현(hedge)하며 질문을 더 많이 한다고 가정했기 때문에, 한 검사는 'I think'가 전혀 없는 긴 메시지를 플래그했고 다른 하나는 질문이 없는 메시지를 플래그했습니다. 저의 자체 메시지 중 100단어가 넘는 경우, 완곡한 표현(hedge) 검사가 80%의 확률로 작동했습니다. 제가 무언가를 알 때는 대부분 그냥 말합니다. 두 검사 모두 사라졌습니다.

Bar chart of how often each structural check flagged 163 of my own sent messages, with a 25% cut-off line. Cut: no hedge anywhere 36%, no question back 34%. Kept: much longer than the question 20%, paragraphs all the same size 4%, long for a chat reply 3%, assistant opener 1%, pseudo-wisdom 1%.

남아있는 것은 반대편 검사, 즉 거의 모든 줄에 걸친 완곡한 표현인데, 이 역시 매우 가짜처럼 보입니다. 제가 지금 작성하는 규칙은 간단합니다. 실제로 확인된 사실은 명확하게 진술됩니다. 추측에는 사람이 사용하는 종류의 개인적인 완곡한 표현을 사용하고, 'it may be the case that' 같은 표현은 사용하지 않습니다. 그리고 모르는 것이 있다면 단서를 붙이는 대신 질문을 합니다.

길이 검사는 남아있지만, 여전히 5개 중 약 1개의 메시지에서 작동합니다. 저는 그 메시지들을 살펴봤고, 그것들은 짧은 질문에 대한 길었던 답변들이었고, 저에 의해서든 아니든 더 짧았어야 할 내용들이었습니다.

한 개의 문을 통해 들어가면, 다른 하나의 문으로 나가기

모든 초안은 제가 보기 전에 하나의 스크립트를 거칩니다. 하드(Hard)한 것은 블록 형태로 표시되고, 소프트(Soft)한 것은 처리해야 할 경고로 돌아옵니다. 또한 각 채널별로 전송 단계에서 검사가 이루어지므로, 측로로는 아무것도 나가지 않습니다.

두 번째 검사에서 버그가 바로 발견되었습니다. 해당 훅(hook)은 두 개의 채널에 등록되었지만, 스크립트의 case statement에는 이들을 위한 분기문이 없어 아무런 확인 없이 모든 것을 통과시켰습니다. 설정에서는 '포함됨(covered)'이라고 되어 있고 코드에서는 '건너뛰기(skip)'라고 되어 있었습니다. 이 두 채널에서 가장 어색한 텍스트가 나왔던 곳입니다. 한 줄 수정으로 해결되었고, 설정을 보고는 절대 찾지 못했을 것입니다.

나의 편집 내용으로부터 학습합니다

제가 초안을 다시 작성하거나 기계처럼 들려서 버릴 때, 이전 버전과 이후 버전이 기록됩니다. 밤마다 하나의 작업(job)이 그날의 쌍들을 읽고 이들로부터 짧은 스타일 규칙을 만듭니다. 예를 들어, '피드백에 답변할 때는 제기된 요점만 답하고 따뜻한 마무리 인사말은 생략한다' 또는 '부드러운 문장으로 끝내지 말고 구체적인 질문으로 끝낸다'와 같은 것입니다. 이 규칙들은 다음 초안에 자동으로 로드됩니다.

Flow diagram: my notes, first draft from a model, linter, me (read, rewrite, decide what goes), send check, out. My edits go to a log, a nightly job turns them into style rules (max 6 a night, 25 in total), and the rules are loaded into the next draft.

저는 이 루프를 짧게 통제했습니다. 밤에 최대 6개의 규칙만 추가할 수 있고 총 25개로 유지되며, 규칙은 스타일과 관련된 것일 뿐 제가 승인해야 할 내용에 관한 것이 아니며, 파일은 제가 원할 때 편집하거나 삭제할 수 있는 일반 텍스트입니다. 모델이 스스로 지침을 작성하는 것은 혼란스러운 결과를 초래하기 쉬우므로, 작업할 수 있는 작은 상자를 제공받습니다.

이것이 하지 않는 것

무엇을 말해야 할지 결정하지 않습니다. 단지 어떻게 말하는지만 다듬어 줍니다. 상대방이 실제로 무엇을 요청했는지, 제가 무엇을 약속할 수 있는지, 그리고 어떤 문장이 적절한 답변인지 아는 것은 여전히 제 일이며, 저는 도구가 그 부분을 맡아서는 안 된다고 생각합니다.

만약 팀에서 AI를 사용하여 지원 응답, 영업 이메일 또는 보고서를 작성한다면, 고객들이 이를 알아차리기 시작했을 때도 이 접근 방식은 적용됩니다. 본인이 보낸 메시지가 데이터셋이며, 어색한 부분(tells)은 측정 가능합니다. 저는 이런 종류의 툴링을 만드는 것을 좋아합니다.

본문은 hrolgar.com에 처음 게시되었습니다.