컴퓨터과학 리포트와 AI 탐지: 코드, 의사 코드, 그리고 그 사이의 산문

Turnitin이 코드에 대해 공개한 입장은 짧고 분명합니다. 모델은 "does not reliably detect AI-generated text in the form of non-prose, or code" (산문이 아닌 형태, 즉 코드 형태의 AI 생성 텍스트를 안정적으로 탐지하지 못합니다) 라고 되어 있고, FAQ는 Turnitin이 "not pursuing ChatGPT code detection at this time." (현 시점에서는 ChatGPT 코드 탐지를 추진하지 않습니다) 라고 덧붙입니다. 따라서 코드 목록과 의사 코드 블록, 터미널 실행 기록은 AI 비율이 겨냥하는 대상이 아닙니다. 대상은 그 사이의 단락이며, CS 리포트에서 그것은 설계 근거, 알고리즘 설명, 복잡도 분석, 평가 논의를 뜻합니다. 그리고 그 단락은 문서에서 가장 균일한 글이기도 합니다. 좋은 기술 문서는 균일해야 하기 때문입니다.

그 모든 것과는 별개로, 학과에서 무엇을 생성해도 되는지를 정하는 것은 탐지 도구가 측정하는 것이 아니라 학과의 학술 진실성 정책입니다. 한쪽 질문에 답한다고 해서 다른 쪽 질문에 답이 되는 것은 아니며, 둘을 같은 질문으로 취급하는 것이 사람들이 면담 자리에 앉게 되는 경로입니다.

이 모든 것을 떠받치는 문장은 두 개입니다. 첫 번째는 FAQ의 '무엇이 분석되는가'에 대한 정의 안에 있습니다.

"The model does not reliably detect AI-generated text in the form of non-prose, or code, nor does it detect short-form/unconventional writing such as bullet points (short non-sentence structures)." (모델은 산문이 아닌 형태나 코드 형태의 AI 생성 텍스트를 안정적으로 탐지하지 못하며, 불릿 포인트처럼 짧고 비표준적인 형태의 글, 즉 문장 구조가 아닌 짧은 구조도 탐지하지 못합니다.)

한 줄만 더 읽어 보십시오. 바로 그다음에 쓸모 있는 부분이 나옵니다.

"This means that a document containing several different writing types would result in a disparity between the percentage and the highlights." (이는 여러 가지 서로 다른 글 유형이 담긴 문서에서는 비율과 강조 표시 사이에 불일치가 생길 수 있음을 뜻합니다.)

CS 리포트는 태생적으로 여러 가지 다른 글 유형이 담긴 문서입니다. 따라서 그 불일치는 이 장르에서 예외적인 상태가 아니라 정상적인 상태입니다. 리포트 가이드도 같은 제외를 더 긴 목록으로 밝히면서, 코드와 함께 시와 대본을 언급하고, 짧은 형식 쪽에 표와 주석 달린 참고문헌 목록을 추가합니다.

두 번째 문장은 대개 주변 맥락 없이 돌아다니므로, 어디에 있는지 짚어 둘 만합니다. 그것은 "Why is AI detection not being added to Gradescope?" (AI 탐지 기능이 Gradescope에 추가되지 않는 이유는 무엇인가요?) 라는 질문에 대한 답변의 마지막 줄입니다. 그 답변은 이렇게 이어집니다. Turnitin은 "not currently have plans to add these capabilities to Gradescope, since the primary use case for Gradescope is handwritten text while for AI detection we're focusing on typed text" (Gradescope의 주된 사용 사례는 손글씨 텍스트인 반면 AI 탐지는 입력된 텍스트에 집중하고 있으므로, 당분간 이 기능들을 Gradescope에 추가할 계획은 없습니다) 라고 밝힌 뒤, "In addition, we are not pursuing ChatGPT code detection at this time." (또한 현 시점에서는 ChatGPT 코드 탐지를 추진하지 않습니다) 라고 덧붙입니다.

이 점은 다른 어떤 학문보다 컴퓨터과학에서 중요합니다. 프로그래밍 과제 상당수가 Gradescope로 제출되기 때문입니다. 구현물은 자동 채점기로, 작성한 리포트는 Turnitin 과제로 넘어간다면 그것은 역할이 다른 두 경로이며, 최종적으로 보게 되는 AI 작성 비율은 두 번째 경로에서 계산된 값입니다. 이 분할의 라이선스 측면은 어느 Turnitin 제품에 AI 탐지가 있는지에서 다룹니다.

정의는 리포트 가이드에 나와 있고, 거기 제시된 예시는 눈여겨볼 만합니다.

"Qualifying text (prose sentences contained in long-form writing format) means individual sentences contained in paragraphs that make up a longer piece of written work, such as an essay, a dissertation, or an article, etc." (Qualifying text, 즉 장문 작성 형식에 담긴 산문 문장이란 에세이, 학위 논문, 논문 등 더 긴 저작물을 이루는 단락에 포함된 개별 문장을 말합니다.)

에세이, 학위 논문, 논문. API 레퍼런스의 문체로 쓰인 프로젝트 리포트는 이 셋 중 어디에도 해당하지 않으며, Turnitin은 그에 대한 판단을 공개하지 않습니다. 공개된 것은 문장 기준이므로, 그 기준을 요소별로 적용한 것이 아래 표입니다. 이것은 저희가 만든 대응표이며, 업체의 것이 아닙니다.

그 표에서 두 가지 결론이 나옵니다. 분모가 작으므로 비율은 파일 전체가 아니라 파일의 한 조각에 대한 진술이며, FAQ는 이를 이렇게 그대로 밝힙니다. "This percentage is not necessarily the percentage of the entire submission. If text within the submission is not considered long-form prose text, it will not be included." (이 비율이 반드시 제출물 전체의 비율인 것은 아닙니다. 제출물 안의 텍스트가 장문 산문으로 간주되지 않으면 포함되지 않습니다.) 또한 목록이 많은 리포트라면 대상 텍스트가 충분히 적어져서 짧은 문서에서 나타나는 전부 아니면 전무 방식이 문제가 될 수 있습니다. 파일 요건에는 리포트가 아예 생성되려면 "at least 300 words of prose text in a long-form writing format" (장문 작성 형식의 산문 텍스트가 최소 300단어) 이 필요하다고 나와 있습니다.

Turnitin은 오탐지에 공통으로 나타나는 특징을 공개하고 있습니다.

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas." (오탐지, 즉 사람이 쓴 텍스트를 AI 생성으로 잘못 표시하는 경우에는 구조적 변화가 거의 없는 내용, 말 그대로 자기 자신을 반복하는 텍스트, 새로운 생각을 전개하지 않고 바꿔 쓴 텍스트가 포함될 수 있습니다.)

그리고 다음 문장은 여러분이 아니라 채점자를 향한 것입니다.

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated." (그러한 텍스트에서 AI 작성 비율이 높게 나타난다면, 표시된 비율을 볼 때 그 점을 고려하시기를 권합니다.)

이제 그 두 가지 속성을 잘 쓴 기술 문서에 대입해 읽어 보십시오. 구조적 변화는 레퍼런스 절이 의도적으로 제거하는 것입니다. 모든 함수가 이름, 매개변수, 반환값, 실패 모드라는 같은 틀을 갖추므로, 틀을 한 번 익힌 독자는 나머지를 훑어볼 수 있습니다. 같은 내용을 같은 방식으로 두 번 쓰는 것은 두 구성 요소가 똑같이 동작한다고 독자에게 알리는 바로 그 방법입니다. 항목마다 형태를 바꾸라고 하는 스타일 가이드는 좋은 스타일 가이드가 아닙니다.

같은 형태가 알고리즘 설명에도 다른 이유로 나타납니다. 그 절은 대개 바로 위 목록이 이미 말한 것을 영어로 다시 풀어 씁니다. 어떤 내용을 되풀이하는 것은 문체상 갈 곳이 없습니다. 모든 단계가 그 단계 자체로 시작하고, 모든 문장의 주어가 같으며, 그 단락은 제어 흐름을 그대로 옮겨 적은 기록이 됩니다.

여기에는 솔직히 인정해야 할 한계가 두 가지 있습니다. Turnitin은 그 속성의 빈도를 제시하지 않고 오탐지가 포함할 수 있는 것의 목록만 밝히므로, 이 효과가 얼마나 설명되는지는 아무도 말할 수 없습니다. 또한 모델의 동작은 거꾸로 추론할 수 있는 규칙집이 아닙니다. FAQ에는 "Our model is not explicitly programmed to evaluate specific signals such as 'burstiness,' 'perplexity,' or other individual metrics sometimes referenced in public discussions." (저희 모델은 'burstiness,' 'perplexity,' 같은 특정 신호나 공개 논의에서 종종 언급되는 개별 지표를 명시적으로 평가하도록 프로그래밍되지 않았습니다) 라고 나와 있습니다. 퍼플렉시티와 버스티니스에 대한 오해에 더 온전한 설명이 있으며, 같은 페이지 다른 곳에 있는, 그 문장을 과하게 읽지 않도록 막아 주는 문장도 함께 다룹니다.

CS 리포트를 에세이와 다르게 만드는 비대칭이 여기에 있습니다. 측정에서 제외되는 내용은 움직이지 않는 배경이 아닙니다. 그것은 문자 하나만 바뀌어도 문서가 틀려지는 부분이며, 누군가 점수를 매기든 매기지 않든 교정 과정에서 읽히는 부분입니다.

눈에 잘 띄지 않는 두 번째 실패도 있습니다. 결과물이 아주 자연스럽게 읽히기 때문입니다. 기술 문서는 하나의 개념에 하나의 이름을 붙입니다. 교정 후 같은 객체를 3장에서는 `hash map`, 4장에서는 `dictionary`로 남기거나, `worker`와 `thread`를 번갈아 쓴다면, 그 문서는 그것이 하나인지 둘인지 독자에게 알려 주지 않게 되며, 채점자도 여러분의 코드를 읽지 않고는 판단할 수 없습니다. 그것은 문서에 가해진 손상이고, 여기에도 점수는 관여하지 않습니다. 다른 모든 곳에서 도움이 되는 습관과 어긋나므로 분명히 말해 둘 만합니다. 대부분의 글에서 정의된 용어는 단어 선택이지만, 이 장르에서는 그것이 식별자에 가깝습니다.

이 가운데 어느 것도 이미 열어 둔 도구 외에 다른 도구를 필요로 하지 않습니다.

• 문서에 있는 명령을 모두 복사해 임시 디렉터리에서 실행해 보십시오. 설치 안내는 가장 먼저 낡아지고, 아무도 다시 읽지 않는 부분입니다.
• 코드가 정의한 식별자를 모두 목록으로 만들고, 각각을 문서에서 검색해 보십시오. 코드에는 있는데 문서에는 없는 것이 있다면, 여러분 모르게 이름이 바뀐 것입니다.
• 가장 중요한 개념 용어 다섯 개를 골라 각각 검색해 보십시오. 하나의 개념에는 하나의 이름, 모든 곳에서 동일해야 하며, 그렇지 않다면 지금 고치십시오.
• 복잡도 주장은 그것이 설명하는 함수와 대조해서 읽어 보십시오. `O(n log n)`과 "효율적"은 서로 바꿔 쓸 수 없으며, 채점 대상이 되는 것은 둘 중 하나뿐입니다.
• 따옴표 안의 내용은 실제 실행 결과와 대조해 보십시오. 로그 줄과 오류 메시지는 인용입니다.

지적된 블록이 알고리즘 설명이라면, 문장을 건드리기 전에 물어볼 만한 질문이 있습니다. 그 절은 바로 위 목록이 이미 하지 않는 일을 하고 있습니까? 변수 이름만 바꾸고 단계 사이에 "그다음"을 넣은 설명은, 어떤 탐지 도구가 뭐라고 하든 리포트 안의 중복 콘텐츠입니다. 자리를 얻을 만한 버전은 그 반복문이 왜 그런 구조인지, 대안은 무엇이었는지, 어디에서 무너지는지를 설명합니다.

또한 그곳은 여러분의 글이 나아갈 곳이 있는 지점이기도 합니다. 설계 근거, 기각한 대안, 이틀이 걸린 버그, 벤치마크가 측정하지 못하는 것, 일주일만 더 있으면 고쳤을 한계. 그 단락들은 그 안의 사고가 달라지는 만큼 형태도 달라집니다. 레퍼런스 스타일의 절은 달라지지 않으며, 달라져서도 안 됩니다.

그 조언의 한계에 대해서는 분명히 말해 두겠습니다. 저는 리포트를 읽기 좋게, 채점하기 좋게 만드는 것이 무엇인지를 설명하고 있습니다. 그것이 숫자에 어떤 영향을 주는지는 저희를 포함해 아무도 말할 수 없습니다. Turnitin은 풀링 함수나 세그먼트 길이를 공개하지 않으며, 자사 모델이 "may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student." (항상 정확한 것은 아닐 수 있습니다. 사람이 쓴 텍스트, AI가 생성한 텍스트, AI가 바꿔 쓴 텍스트를 잘못 판별할 수 있으므로, 학생에게 불리한 조치를 취하는 유일한 근거로 사용해서는 안 됩니다) 라고 경고합니다.

CS 리포트의 교정이 느려지는 이유는 문장과는 크게 관련이 없습니다. 다시 쓴 단락 하나에 식별자 네 개와 플래그, 버전 번호가 들어 있을 수 있고, 그 단락을 신뢰하려면 각각을 코드와 다시 맞춰 봐야 합니다. 비용은 손댄 단락 수로 헤아리십시오.

그래서 HumanPen 도구는 먼저 범위를 지정하게 합니다. 문서를 업로드한 뒤, 교정할 부분에 표시를 하거나 Turnitin 또는 iThenticate의 AI 리포트를 가져와 지적된 부분이 경계를 그리도록 하십시오. 그 밖의 부분은 전혀 건드리지 않으며, 이 장르에서 그것은 여러분이 직접 넣지 않는 한 코드 목록과 명령 블록이 아예 교정 대상에 들어가지 않는다는 뜻입니다. 엔진은 단락보다 작은 단위로는 동작하지 않으므로, 단락 중간에서 끝나는 선택은 단락 전체를 덮도록 넓혀지고 먼저 여러분에게 확인용으로 표시됩니다. 크레딧은 실제로 다시 쓰인 단어 수대로 계산됩니다. 용어는 구조, 인용, 레이아웃과 함께 유지 대상 목록에 들어 있습니다. 그래도 지적된 상태로 남은 부분은 조건이 충족되는 경우 무료로 다시 교정할 수 있습니다.

다운로드 후 복잡한 문서를 검토한다는 내용이 FAQ에 한 줄 있습니다. 식별자가 가득한 리포트에서 그것은 처음부터 끝까지 읽어 보라는 뜻이 아니라, 앞 절의 점검 목록을 뜻합니다. 필드와 상호 참조를 포함해, 문서 수준에서 왕복 과정에서 깨지는 것들은 Word 필드, 목차, 상호 참조에서 다룹니다.

Turnitin은 AI가 생성한 코드를 탐지합니까? Turnitin은 자사 모델이 산문이 아닌 형태나 코드 형태의 AI 생성 텍스트를 안정적으로 탐지하지 못한다고 밝히며, FAQ는 현 시점에서 ChatGPT 코드 탐지를 추진하지 않는다고 말합니다. 그것은 이 리포트가 무엇을 측정하는지에 대한 진술입니다. 여러분의 학교가 무엇을 허용하는지에 대한 진술이 아니며, 그건 여러분이 읽어야 할 별개의 문서입니다.

제 의사 코드 블록도 채점됩니까? 공개된 규칙은 모델이 단락 안의 산문 문장을 분석한다는 것이며, 짧은 형식과 문장이 아닌 구조는 탐지하지 않는 대상으로 명시되어 있습니다. 의사 코드 블록은 문장 구조가 아니라 행 구조입니다. 그것을 소개하는 단락은 산문입니다.

강조 표시가 한 절에 이렇게 몰려 있는 이유는 무엇입니까? 부분적으로는 산술의 문제입니다. 파일 대부분이 제외되면 강조 표시는 남은 부분에만 나타날 수 있습니다. Turnitin은 겹치는 세그먼트에 점수를 매기고 그 값을 풀링한다고도 설명하므로, 균일한 텍스트 구간은 흩어진 결과가 아니라 균일한 결과를 내는 경향이 있습니다.

복잡도 분석 절이 지적되었는데, 한 글자 한 글자 제가 썼습니다. 그럴 수 있습니다. 채점자 앞에 내놓을 것은 오탐지에 관한 FAQ 단락이며, 특히 표시된 비율을 읽을 때 텍스트의 속성을 고려하라는 마지막 문장입니다. 다만 그것이 저자 여부를 결정해 주지는 않으며, 어느 방향으로도 마찬가지입니다.

리포트가 거의 목록뿐이라 AI 리포트가 생성되지 않았습니다. 무언가 실패했다고 단정하기 전에 하한선을 확인해 보십시오. 파일 요건에는 장문 작성 형식의 산문 텍스트가 최소 300단어 필요하다고 나와 있으며, 목록이 많은 리포트는 페이지 수가 넉넉해 보여도 그 아래에 머물 수 있습니다. 일반적인 제외 목록은 Turnitin AI가 건너뛰는 콘텐츠에 있습니다.