CiteTrue와 Google Scholar 비교
의심스러운 참고문헌을 손으로 확인할 때 대부분이 여는 곳이 Google Scholar이고, 한 건이라면 충분히 통하는 방법입니다. 마흔 건이 되는 순간 방법이기를 그만둡니다.
우리 판정이 버티는 이유
대부분의 인용 검증 도구는 판단 전체를 언어 모델에 맡기고 모델이 한 말을 그대로 보여 줍니다. 하지만 모델은 환각을 일으킵니다 — 이 분야가 존재하는 이유가 바로 그것입니다. 그래서 우리는 모델을 맨 앞이 아니라 맨 뒤에 둡니다.
- 01
1. 추측하지 않고 구문 분석한다
모든 참고문헌은 저자, 제목, 연도, 학술지, DOI 같은 요소로 분해됩니다. 분해하는 것은 인용 형식을 위해 만들어진 파서이지, 제목이 무엇 같으냐고 모델에게 묻는 방식이 아닙니다.
- 02
2. 권위 있는 데이터베이스에서 대조한다
분해된 참고문헌을 Crossref와 OpenAlex에 조회하고, DOI가 없으면 공개 웹에서도 찾습니다. 돌아오는 것은 실제 식별자를 가진 실제 레코드입니다.
- 03
3. 일치도를 결정론적으로 점수화한다
후보 레코드는 제목 토큰에 대한 Sørensen-Dice 유사도로 점수를 매깁니다. 제목 점수가 0.7을 넘고 저자 목록이 일치할 때만 일치로 인정합니다. 연도가 어긋나면 안내로 표시할 뿐, 조용히 넘어가지 않습니다. 같은 참고문헌은 언제나 같은 점수를 냅니다.
- 04
4. 그다음에야 모델에게 묻는다
언어 모델은 결정론적 단계에서 진짜 일치를 찾지 못했을 때만 호출합니다. 후보와 원문을 읽고 맞는 것이 있는지 판단하게 하는 것이죠. 모델은 최후의 수단이지 심판이 아닙니다. 바로 이 순서 때문에 환각이 끼어들 자리가 없습니다. 모델이 등장하는 시점에는 이미 근거가 다 나와 있으니까요.
실질적인 의미는 이렇습니다. 여기서 진짜라고 표시된 참고문헌은 제목과 저자 모두에서 실제 레코드와 일치했고, 그 레코드를 직접 열어 볼 수 있습니다. 인용이 그럴듯해 보인다는 모델의 인상이 아닙니다.
참고문헌 목록을 처리하는 속도
한 건을 확인하는 데도 여러 출처에 여러 번 조회가 들어갑니다. 그것을 한 건씩 순서대로 처리하는 것이 긴 목록에서 느리게 느껴지는 이유입니다. 우리는 병렬로 돌리고 끝나는 대로 결과를 내보냅니다.
- 병렬로 처리하는 참고문헌 수
- 앱에서는 한 번에 20건, API로는 100건
- 참고문헌 50건짜리 목록
- 50건을 줄 세우는 대신, 세 차례의 병렬 조회로 내보냅니다
- 도착하는 대로 결과 표시
- 참고문헌 단위로 스트리밍 — 나머지가 도는 동안 먼저 끝난 판정부터 읽습니다
- 대량 작업
- 지도교수 앞에 쌓인 논문 더미는 앱의 5배 동시성으로 API를 통과합니다
서로 다른 역할을 비교하면
| 비교 항목 | CiteTrue | Google Scholar |
|---|---|---|
| 무엇을 위해 만들어졌나 | 이미 가지고 있는 참고문헌 목록을 검증하기 | 아직 없는 문헌을 찾기 |
| 참고문헌 40건 확인하기 | 한 번 붙여넣고 몇 분, 남는 보고서 하나 | 손으로 하는 검색 40번과 40번의 판단 |
| 그 출처가 주장을 뒷받침하나 | Deep Verify가 원문을 읽고 바로 그 질문에 답합니다 | 직접 읽고 판단합니다 |
| 지어낸 참고문헌 탐지 | 참고문헌별 명시적 판정과 그 근거 | 결과가 없다는 사실 — 해석은 본인 몫입니다 |
| 비용 | 하루 30건 무료, 이후 $5.99/월부터 | 무료 |
| 편의성 | 참고문헌 목록 전체를 한 번에, 여기에 확장·앱·API까지 | 브라우저 탭에서 한 번에 한 건씩 |
그래서 무엇을 써야 하나
논문을 찾기에는 Google Scholar가, 마흔 건을 한꺼번에 확인하기에는 CiteTrue가 낫습니다. 결국 대부분 둘 다 씁니다 — 쓸 때는 Scholar, 제출 전에는 CiteTrue.