비정형 표현을 표준값에 맞출 때의 오접 문제

월요일 오전 11시 9분, 에이전트코리아에서는 영화 이야기와 가벼운 농담이 오가던 사이에 한 참가자가 짧은 문장을 올렸다.

시멘틱 온톨로지 서버 구성하려는데

온톨로지는 한 분야의 개념과 그 관계를 구조로 정리한 틀을 가리키는 말로 쓰였다. 질문자는 구축해 본 사람이 있는지 물었다. 이 토픽에는 다섯 명이 71건의 발화를 남겼고, 대화는 11시 10분 무렵부터 정오 넘어서까지 띄엄띄엄 이어졌다.

구조가 먼저라는 설명

가장 먼저 답한 참가자는 시멘틱 온톨로지 서버 도구를 소개했다. 개인형 온톨로지를 다루되 시멘틱웹(웹 데이터에 의미 관계를 붙이는 방식)의 방법론을 적용한 도구라는 설명이었고, 핵심 조건은 이랬다.

시멘틱한 부분이 구조로 잡혀있어야 해요

이 참가자는 OWL이나 RDF 같은 것은 개념만 알면 된다고도 했다. 참고 자료를 묻는 말에는 온톨로지 개발 입문 자료와 한 학자의 방법론을 꼽았고, PROV-O, SHACL 등 여러 약어를 나열했다. 이 약어들은 대화에서 풀이 없이 이름만 오갔다. 이 기사에서 SHACL은 데이터가 정해진 형식을 지키는지 검사하는 규칙을 가리키는 것으로 풀어 읽는다(일반적 용법이며 대화의 설명은 아니다).

그가 강조한 것은 의미를 구조로 잡아 두는 일이었다. 사용자의 AI가 구조 없이 마음대로 만들려 하면 막아 버린다고 했고, MCP(AI가 외부 도구를 부르는 연결 규격) 도구를 짤 때 그 구조가 처음부터 들어가야 한다고 했다. 온톨로지에서 가장 중요한 부분은 EVIDENCE, 곧 근거와 SHACL이라고 보라고 했고, 그렇지 않으면 사고가 난다고 못 박았다. 한편 정통 방법론을 그대로 적용하는 것은 컴퓨터를 쓰는 시기에 서예를 배우는 개념이라는 비유도 덧붙였다. 요즘은 주로 JSONL(한 줄에 데이터 하나씩 적는 형식)이나 jsonld 형식으로 적용한다고도 했다.

질문한 참가자는 사용자가 주는 자료에 도메인 관계는 있어도 의미 층위는 없지 않느냐고 되물었고, 지식 추출 다음 단계가 시멘틱 온톨로지인지도 확인했다. 답은 스키마 과정의 중심에 시멘틱 개념이 구조화되어야 한다는 것이었다.

오접률이라는 다른 질문

11시 18분 다른 참가자가 설계내역서 검토를 자동화해 보려는 사람이 이 방에 없느냐고 물었고, 이어 구체적인 막힘을 적었다.

비정형 데이터를 표준 기준에 매칭을 하는 오접률 오탐율 줄이는 방법에서 막혀서 아는분이 계신가하고 여쭤봅니다 ㅎㅎ..

이 질문을 한 참가자는 정오 가까이 되어 상황을 풀어 썼다. 그에 따르면 설계하는 사람마다 같은 표현을 조금씩 다르게 적는데 그 동의어와 유사어를 모두 표준값에 맞춰야 하고, 그 과정에서 오접, 곧 엉뚱한 표준값에 연결되는 일이 꽤 늘었다는 것이다. 질문자는 어떤 도구를 써 봤지만 자신이 서툰 탓인지 크게 개선되지 않았다고 했다.

앞서 11시 20분 무렵 한 답변자는 표준 기준이 규격과 단가일 것 같다고 되물으면서, 자신들은 아이템의 규격과 단가를 모두 코드로 만들어 두었다고 했다.

저희는 아이템 규격 단가를 모두 코드화 해놔서

그래서 비정형 아이템이 견적 단계에서 문제가 되는 경우가 많지 않다는 경험을 전했다. 이 답은 질문자가 겪는 상황, 곧 사람마다 표현이 다른 입력이 들어오는 상황과는 출발점이 다르다. 코드화가 이미 되어 있는 쪽의 경험을 비정형 입력의 오접 해법으로 곧바로 옮기기는 어렵다.

두 가지 답

정오 무렵에는 시멘틱 온톨로지 서버를 처음 물었던 참가자가 결국 매핑을 잘하는 문제일 것 같다고 하면서, 자기가 해 본다면 벡터 DB(문장 뜻이 비슷한 것끼리 찾아 주는 저장소) 쪽이나 소형 LLM으로 하지 않을까 싶다고 했다. 이는 직접 해 본 방법이 아니라 가정이다. 대화 기록상 이 두 발언과 아래 경험담은 같은 화자의 것이다.

제가 해본다면 Vector db쪽이나 소형 llm으로 하지않을까 싶어요

같은 참가자는 가정으로 먼저 답한 뒤, 12시 12분에 직접 겪은 방법도 덧붙였다.

저는 일단 비슷한 상황에서 온톨로지 노드에 유사 단어 목록 추가해서 llm이 추론에 도움되도록 했었습니다.

이 방법으로 오접이 얼마나 줄었는지에 대한 수치나 질문자의 반응은 이 토픽에 없었다.

해석

이 문답에서는 두 개의 서로 다른 질문이 한 줄기로 이어졌다. 앞의 질문은 어떻게 짓느냐였고, 뒤의 질문은 이미 지은 틀에 사람마다 다르게 적은 입력을 어떻게 안전하게 맞추느냐였다. 앞의 답은 근거와 SHACL을 구조에 넣으라는 원칙에 가까웠고, 뒤의 답은 유사 단어 목록 같은 구체적 보조 장치였다. 그 사이에 오접을 실제로 얼마나 줄이는지를 보여 주는 사례는 나오지 않았다.

다만 다섯 명의 대화이고 설계내역서의 구체적 양식이나 표준값의 규모도 공개되지 않았다. 이 방법들이 그 문제에서 통할지는 이 대화만으로 판단하기 어렵다.