article · 2026-08-06
엔티티를 알수록, 모델은 덜 일할까
컴퓨터가 이미 아는 이름을 먼저 찾게 했더니 생긴 뜻밖의 일. 37.0% 진행 중간 기록
도서관 사서에게 책 제목을 하나씩 보여 준다고 생각해 보자.
처음에는 사서가 매번 책을 펼쳐 보고, 무슨 책인지 알아봐야 한다. 그런데 같은 책이 계속 들어온다면 조금 다르게 할 수 있다. 표지와 제목을 먼저 보고 “이 책은 전에 봤어”라고 표시한다. 정말 낯선 책만 자세히 펼쳐 본다.
문서를 AI가 읽는 일도 비슷하다. 문장에는 GLiNER, SQLite, Docling처럼 같은 이름이 계속 나온다. 이 이름들을 매번 AI에게 다시 물으면 느리고 돈도 든다. 그래서 먼저 작은 이름표 목록에서 찾아보고, 목록에 없는 말만 AI에게 보낸다.
이 실험의 질문은 간단하다.
이미 아는 이름을 많이 모아 두면, AI는 정말 일을 덜 하게 될까?
그 전에 더 까다로운 질문이 있다. 같은 이름은 정말 같은 대상을 뜻할까?
셀은 하나의 이름표가 아니다
셀이라는 말은 하나지만 뜻은 하나가 아니다.
생물 시간의 셀은 세포다. 배터리 문서의 셀은 전기를 담는 작은 단위다. 엑셀 문서의 셀은 표 안의 칸이다. 글자는 같은데, 컴퓨터가 연결해야 할 대상은 셋이다.
그래서 이름표 목록에서 셀을 찾았다고 바로 “이것은 전에 알던 셀”이라고 붙이면 안 된다. 단어를 찾는 일과 대상을 찾는 일은 다르다. 앞의 일은 후보를 고르는 일이고, 뒤의 일은 그 후보가 정말 맞는지 확인하는 일이다.
셀을 분열시킨다, 셀의 전압을 측정한다, 셀 값을 계산한다를 비교해 보면 쉽게 보인다. 같은 단어라도 문장이 말하는 행동이 다르면, 가리키는 대상도 달라진다. 어느 분야의 문서인지도 힌트가 된다. 생물 보고서, 배터리 시험 기록, 스프레드시트 사용법은 같은 사전을 쓰지 않는다.
이 세 문장을 하나의 이름표로 묶으면 나중에 문제가 커진다. “세포를 찾는 사람”에게 배터리 전압 표가 나오고, “엑셀 계산”을 찾을 때 생물학 문장이 섞일 수 있다. 더 나쁜 일도 있다. 지식 그래프가 서로 다른 대상을 같은 것으로 믿게 된다.
이름표는 후보를 찾고, 문맥이 뜻을 고른다
그래서 hash도 단어 하나에 찍는 도장이 아니다. 먼저 셀처럼 글자가 같은 후보 묶음을 빠르게 찾는다. 그다음 문서의 분야, 문장 앞뒤의 말, 그리고 무엇이 무엇을 한다는 관계를 함께 본다. 뜻을 고른 뒤에야 정식 이름표에 연결한다.
같은 글자 찾기 → 뜻 후보 여러 개 → 문서 분야와 문장 관계 확인 → 정식 이름표
확신할 수 없는 경우에는 서두르지 않는다. 임시 칸에 남기거나 AI에게 문장을 다시 읽힌다. 이름표 목록이 AI 호출을 줄이는 데 쓰이더라도, 단어가 보였다는 이유만으로 문장을 건너뛰면 안 되는 이유가 여기 있다.
동음이의어는 단서 여러 개로 푼다
triple은 그중 하나다. 셀의 전압을 측정한다에서 전압과 측정한다는 배터리 셀 쪽을 밀어 준다. 셀을 분열시킨다는 세포 쪽이다. 단어 하나만 보는 대신, “무엇이 무엇을 하고 무엇과 연결되는지”를 보면 뜻이 조금씩 좁혀진다.
하지만 triple 하나로 끝나지 않는다. subject도 predicate도 애매할 수 있다. 그래서 다섯 가지 단서를 함께 둔다.
| 무엇을 보나 | 셀의 뜻을 고를 때 쓰는 힌트 |
|---|---|
| 문서의 분야 | 배터리 시험 기록, 생물 실험 노트, 엑셀 사용 설명 중 어디에서 왔는가 |
| 문장 속 관계 | 전압을 측정한다인가, 분열한다인가, 값을 계산한다인가 |
| 주변의 이름과 숫자 | 전류, 충전, 3.7V인가. DNA, 배양, 핵인가 |
| 후보의 뜻풀이 | 현재 문장이 ‘세포’, ‘전지를 이루는 단위’, ‘표의 칸’ 중 어느 설명에 더 닮았는가 |
| 문서 전체의 흐름 | 문서 안의 다른 이름들이 어느 분야에서 서로 어울리는가 |
뜻풀이와 문맥을 함께 비교하는 방법은 Word Sense Disambiguation 연구에서 널리 쓰인다. Luo et al.은 문장과 각 뜻의 설명을 함께 읽게 했고, Oele and van Noord은 뜻풀이와 문맥의 닮음을 비교했다. 한 문서 안에서 서로 어울리는 entity들을 함께 보는 방식도 entity linking 연구에서 다룬다. Yang et al.
다섯 단서가 같은 답을 가리킬 때만 정식 entity로 연결한다. 점수가 비슷하면 임시 후보로 남긴다. AI나 사람이 다시 볼 몫이다. “모르겠다”를 남길 수 있어야, 같은 글자를 억지로 같은 지식으로 만들지 않는다.
숫자가 한 번에 답해 주지 않았다
문장 4,032개를 읽힌 시점에 결과를 봤다. AI에게 아예 보내지 않아도 된 문장은 289개였다. 전체의 7.2%다.
그런데 그동안 이름표 목록이 먼저 찾아낸 이름은 5,191개였다.
처음에는 두 숫자가 같이 커질 거라 생각했다. 아는 이름이 많아지면 AI가 읽을 문장도 줄어들 거라고 말이다. 하지만 문장은 생각보다 복잡하다.
GLiNER을 문장 단위로 돌린다라는 문장을 보자. GLiNER이라는 이름은 이미 안다. 그래도 “문장 단위로 돌린다”는 부분은 처음 보는 설명일 수 있다. 이름 하나를 찾았다고 문장 전체를 읽지 않아도 되는 것은 아니다.
처리된 구간의 중앙에 가장 가까운 17,024문장 checkpoint에서도 같은 일이 보였다. AI가 안 읽어도 된 문장은 1,716개, 약 10%였다. 반면 이름표 목록이 찾은 이름은 27,830개까지 늘었다.
아래 표의 중앙 checkpoint는 전체 92,085문장의 중앙이 아니다. 현재까지 처리된 34,048문장 범위의 중앙에 가장 가까운 시점이다. 전체 run의 진짜 중앙은 약 46,000문장 부근이며 아직 도달하지 않았다.
| 관찰 지점 | 누적 처리 문장 | 전체 목표 대비 | AI가 읽은 문장 | AI 생략 문장 | 생략 비율 | 먼저 찾은 이름 | 발견된 이름 중 선조회 비율 | 이름표 목록 |
|---|---|---|---|---|---|---|---|---|
| 첫 checkpoint | 1,024 | 1.1% | 920 | 104 | 10.2% | 63 | 5.6% | 883 |
| 처리 구간 1/4 | 8,000 | 8.7% | 7,259 | 741 | 9.3% | 9,845 | 62.7% | 1,607 |
| 처리 구간 중앙 | 17,024 | 18.5% | 15,308 | 1,716 | 10.1% | 27,830 | 69.9% | 2,397 |
| 처리 구간 3/4 | 26,048 | 28.3% | 23,373 | 2,675 | 10.3% | 57,276 | 75.3% | 3,204 |
| 최신 checkpoint | 34,048 | 37.0% | 30,341 | 3,707 | 10.9% | 98,516 | 80.6% | 3,762 |
먼저 찾은 이름은 이름표 목록이 문장 안에서 찾아낸 횟수다. 발견된 이름 중 선조회 비율은 그 시점까지 나온 모든 이름 언급 가운데, 목록이 모델보다 먼저 찾은 비율이다. 98,516은 “AI가 98,516개를 정확히 맞혔다”는 뜻이 아니다. 같은 이름을 문서에서 몇 번 다시 만났는지 세어 본 값이다. 전체 실험도 아직 진행 중이다. 다만 한 가지는 분명했다. “AI를 덜 부른 비율”과 “이미 아는 이름을 먼저 찾은 비율”은 다른 숫자여야 한다.
지금은 어디쯤 왔나
8월 6일 밤 10시 45분에 다시 실행 로그를 열었다. 34,048문장을 읽었다. 전체 약 92,085문장 가운데 37.0%다. AI가 아예 읽지 않아도 된 문장은 3,707개, 10.9%였다.
이 숫자만 보면 열 문장 중 하나를 아꼈다고 말할 수 있다. 그런데 이름표 목록이 먼저 찾은 이름은 98,516개였다. 문장을 통째로 건너뛰는 일보다, 문장 속에서 이미 아는 이름을 미리 알아보는 일이 훨씬 자주 일어나고 있다.
AI가 새로 찾은 이름은 임시 칸에도 쌓이고 있다. 지금까지 3,123개다. 정식 이름표와 임시 이름표를 합친 목록은 3,762개가 됐다. 이 숫자는 지식이 3,762개 늘었다는 뜻이 아니다. 오타나 비슷한 말, 그리고 아직 뜻을 고르지 못한 동음이의어도 섞일 수 있기 때문이다. 임시 칸은 발견을 기억하는 곳이지, 정답을 선언하는 곳이 아니다.
실험은 아직 절반에도 이르지 않았다. 지금 보이는 것은 결론보다 방향이다. AI를 덜 부르는 지점은 문장을 마구 건너뛰는 곳보다, 이미 아는 이름을 먼저 찾아 AI가 읽을 부분을 좁히는 곳에 있을지 모른다.
이름표 목록은 정답지가 아니다
컴퓨터가 이름을 찾을 때는 글자를 조금 다듬은 뒤, 그 글자로 만든 짧은 번호를 이름표 목록에서 찾는다. 이 짧은 번호를 hash라고 부른다. 사람으로 치면 긴 이름을 찾아보기 쉽게 카드 번호로 바꾸는 일에 가깝다. 다만 이 번호는 “같은 글자”를 빨리 찾을 뿐, 같은 뜻을 보장하지 않는다. 그래서 같은 글자의 hash는 entity 하나가 아니라 여러 뜻 후보를 돌려줄 수 있다.
GLiNER, gliner, GLiNER 모델은 같은 대상을 말할 가능성이 있다. 이런 표현을 하나의 이름표 아래에 모아 두면, 문서 여기저기에 흩어진 같은 대상을 연결할 수 있다. 하지만 셀처럼 여러 분야에서 쓰이는 말은 한 이름표 아래에 곧장 넣지 않는다. 먼저 여러 뜻의 후보로 남긴다.
하지만 글자가 같다고 항상 같은 대상을 뜻하지는 않는다. 짧은 약자는 다른 뜻으로도 쓰이고, 새로 발견한 이름은 오타일 수도 있다. 같은 사전 단어도 도메인이 바뀌면 다른 뜻이 될 수 있다. 그래서 이름표 목록은 두 칸으로 나눈다.
한 칸에는 여러 번 확인한 이름을 둔다. 다른 칸에는 AI가 새로 본 이름을 임시로 둔다. 임시 칸의 이름은 바로 지식 그래프의 정답이 되지 않는다. 어느 문장에서 나왔는지, 정말 같은 대상인지 확인한 뒤에만 첫 칸으로 옮긴다.
모르는 이름을 기억하는 것과, 그 이름을 사실로 믿는 것은 다르다.
AI는 모르는 부분만 읽는다
한 문장은 아래 순서로 지나간다.
문장
→ 이름표 목록에서 아는 이름을 먼저 찾기
→ 남은 부분이 있으면 AI에게 보여 주기
→ 새 이름은 임시 칸에 넣기
→ 사람이 확인한 이름만 정식 목록으로 옮기기
AI가 찾는 것은 사람, 도구, 회사, 방법처럼 문장에서 중요한 이름이다. 이런 이름을 엔티티라고 부른다. 이름 사이의 관계도 나중에는 찾는다. 예를 들어 “A가 B를 사용한다”라는 문장은 A, 사용한다, B로 나눠 볼 수 있다. 하지만 “사용한다”라는 말을 봤다고 곧바로 지식 그래프의 규칙으로 정하지는 않는다. 원래 문장과 함께 남겨 두고, 여러 문서에서 같은 뜻으로 쓰이는지 확인한다.
이 순서의 목표는 AI를 없애는 것이 아니다. AI가 이미 아는 이름을 또 맞히는 대신, 정말 낯선 이름과 낯선 설명, 그리고 같은 단어의 다른 뜻을 구별하는 데 시간을 쓰게 하는 것이다.
비슷한 생각은 연구에도 있다
연구자들은 오래전부터 “이미 아는 이름 목록”을 AI의 읽기에 보태 왔다. Song과 동료들은 이런 목록을 넣으면 이름을 찾는 AI가 더 잘 읽을 수 있는지 연구했다.
Wang과 동료들은 새로 발견한 이름을 바로 지식에 넣지 않고, 나중에 확인할 후보로 남기는 방법을 다뤘다. 지금의 임시 칸도 같은 이유로 둔다.
BioNER-Cache처럼 전에 본 결과를 기억해 반복 작업을 줄이는 연구도 있다. 분야는 의학 문서지만, 같은 이름을 매번 처음 보는 것처럼 읽지 않겠다는 생각은 닮아 있다.
아직은 너무 조심스럽다
AI에게 보낼지 말지 고르는 간단한 필터도 붙여 봤다. 아는 이름을 가린 뒤에 낯선 고유명사나 외국어, 버전 번호처럼 보이는 말이 남으면 AI에게 보낸다. 아무 이름도 찾지 못한 문장도 기본적으로 AI에게 보낸다.
처음 1,000문장에서 이 필터가 AI를 건너뛰게 한 문장은 여섯 개뿐이었다. 효율만 보면 아쉬운 숫자다. 하지만 지금은 이 편이 낫다. 새 이름이 들어 있는 문장을 모르고 버리는 일이 더 큰 문제이기 때문이다.
전체 문장을 다 읽힌 뒤에는 숫자를 세 개 같이 볼 생각이다. AI가 덜 읽은 문장 수, 이름표 목록이 먼저 찾은 이름 수, 그리고 필터가 실수로 놓친 새 이름의 표본이다.
이 실험은 결국 AI를 얼마나 적게 쓰는지의 경쟁이 아니다. 컴퓨터가 무엇을 이미 안다고 말할 수 있는지, 무엇은 아직 모른다고 남겨야 하는지를 정하는 일에 더 가깝다.