> 교안 최초 작성: 2026-09-26 · 최신 개정: 2026-09-30 · 1주차 수업: 9월 30일

# 모아 둔 자료를 AI가 근거로 쓰게 만들기 — AKM과 Jev로 시작한 작은 실험

AI에게 자료를 많이 주면 더 잘 답할 것 같았습니다. 그런데 자료가 늘수록 다른 문제가 생겼습니다. 원문과 제 해석이 섞이고, 지금만 유효한 상황이 일반 지식처럼 남았습니다. 검색 결과가 있어도 어떤 자료를 읽어야 하는지 다시 판단해야 했습니다.

이번 사례에서는 AKM으로 자료의 역할과 출처를 정리하고, Jev를 읽을 후보를 고르는 보조 도구로 연결했습니다. 1주차에서 해볼 일은 작습니다. 내 자료 3~5개와 질문 3개로 시작해, AI가 실제로 어떤 근거를 쓰는지 확인합니다.

## GitHub에서 참고한 지식베이스

가장 가까운 사례는 [kb-jev](https://github.com/robebots/kb-jev)였습니다. Markdown 문서를 가져와 Jev로 주제를 분류하고, 애매한 결과는 사람이 검토합니다. 원문은 그대로 두고 분류 결과, 원문 해시, 질문과 분류체계 버전, 모델 정보를 연결합니다. Obsidian에서도 열 수 있습니다.

제가 가져오려는 부분은 원문과 판단을 구분하는 방식입니다. ‘어느 범주에 속한다’는 모델의 선택과 ‘원문에 무엇이 적혀 있다’는 사실이 섞이지 않아야 나중에 판단을 고칠 수 있습니다.

이 저장소가 Jev의 검색 향상을 증명한 것은 아닙니다. 현재 검색은 분류 결과를 순위에 쓰지 않으며 공개 데모는 오프라인 모의 분류입니다. 우리는 구현 구조를 참고하되, 효과는 자신의 자료로 확인합니다. [README의 검증 범위](https://raw.githubusercontent.com/robebots/kb-jev/main/README.md)

## AKM에서는 자료의 역할부터 나눴습니다

AKM에는 원문, 재사용할 지식, 특정 상황의 맥락, 반복 절차와 실행 기록을 구분해 둡니다. 사람이 읽는 설명을 정본으로 삼고 AI도 같은 문서를 참고합니다.

요리 예제로 보면 구분이 쉽습니다. ‘이 실습에서 계란볶음밥에는 밥과 달걀이 필요하다’는 정의와 ‘지금 보관함에는 토마토가 없다’는 현재 상태는 역할이 다릅니다. 후자를 변하지 않는 일반 지식처럼 취급하면 상황이 바뀌어도 같은 답을 할 수 있습니다.

자료를 나눴다는 사실만으로 답이 좋아지지는 않습니다. 그래서 먼저 질문 3개에 대한 기존 답변과 실제 인용을 보존하고, 구조를 정리한 뒤 같은 질문을 다시 묻습니다.

## Jev에는 좁은 판단 하나를 맡겼습니다

Jev는 정해 둔 선택지와 근거를 받아 선택·점수를 반환하는 모델입니다. 이 실습에서는 이미 찾은 후보에 ‘사용’, ‘제외’, ‘검토’를 붙입니다. 후보의 원문을 읽고 답변을 작성하는 일은 주 에이전트가 맡습니다.

```text
원문 보존 → 인덱스와 출처 정리 → 질문으로 후보 찾기
         → 필요할 때 Jev 후보 선별 → 원문 확인과 답변
```

질문을 반박하는 자료도 남겨야 합니다. ‘토마토밥을 만들 수 있지?’라는 질문에 ‘토마토가 없다’는 기록은 중요한 근거입니다. 긍정적인 자료만 모으면 답은 그럴듯해져도 틀릴 수 있습니다.

AKM에는 2026-09-26 공통 판단 절차와 호출 경로를 연결했습니다. 당시 연결 점검 4호출에서 입력 2,293토큰을 사용했고, 합성 자료의 관련성과 동일 개체 후보를 확인했습니다. 이것은 연결 동작을 확인한 기록입니다. 전체 AKM의 정확도나 비용이 개선됐다는 측정은 아직 아닙니다.

별도의 요리 실습 1요청에서는 입력 2,193토큰과 약 232ms가 기록됐습니다. 원래 선택 9개는 기준과 일치했지만 한 개체 판정은 낮은 confidence 때문에 최종 보류됐습니다. ‘모두 자동 처리에 성공했다’고 소개할 수 없는 이유입니다. 이번 스터디멤버 실행 결과도 과거 기록과 별도로 남깁니다.

## 큰 모델을 덜 부르면 얼마나 달라질까

[Neo4j 개체 판별 실험](https://github.com/Kervin-Hu-Neo4j/jev-neo4j-entity-resolution)은 Jev가 후보쌍을 먼저 판단하고 애매한 10.6%만 큰 모델로 넘겼습니다. 공개 결과에서 혼합 방식은 큰 모델 단독과 같은 군집 ARI를 내며 비용을 약 17.3%로 줄였습니다.

다만 영어 합성 연락처의 개체 판별 실험입니다. 제 AKM이나 이번 스터디멤버의 지식베이스에서 같은 절감률이 나온다는 뜻은 아닙니다. 자료가 다섯 개뿐이면 Jev 호출이 오히려 비용과 시간을 더할 수 있습니다. 이를 숨기지 않고, 어떤 경우에는 바로 읽는 편이 나은지 판단하는 것도 결과입니다.

## 두 번째 사례: Ontology + Jev — 분류가 막히면 정의를 돌아보기

[Ontology + Jev](https://github.com/dagfinndybvig/Jev_Ontology)에서는 LLM이 문의 분류체계를 만들고 Jev가 항목을 분류합니다. 모호한 항목이 모이면 정의의 빈틈을 검토하고 다시 평가합니다. 중복 청구 문의를 처리할 `WrongfulCharge`를 추가한 것이 한 사례입니다. 이 저장소의 출발점은 분류 트리이며 형식 논리 추론기를 완성한 사례는 아닙니다.

1주차에 가져올 과정은 **기준 만들기 → 분류하기 → 애매한 이유 찾기 → 정의 한 곳 수정 → 다른 자료로 확인하기**입니다. 기존 요리 자료를 ‘일반 정의·현재 상태·이름 대응·검토’로 구분해 보고, 서로 겹치는 기준을 다듬습니다. 분류 기준도 AKM에 버전과 수정 이유를 남길 지식입니다.

낮은 점수의 원인은 정의의 빈틈일 수도 있지만 입력 부족이나 복합 주제일 수도 있습니다. 보류된 항목마다 새 범주를 만드는 대신 무엇이 부족한지 먼저 적습니다. 한 분류에 억지로 넣기 어려운 문서는 보류하거나 주장 단위로 다시 살펴볼 수 있습니다.

원저자의 티켓 실험에서는 같은 자료의 확신도가 올라갔지만 별도 자료에서의 상승은 반복 실행 변동 범위 안이었습니다. 이를 정확도 향상이나 스스로 발전하는 온톨로지의 증명으로 소개하지 않습니다. [홀드아웃 결과](https://github.com/dagfinndybvig/Jev_Ontology/blob/51311b3dd12b0ef0d8c0fb913ae56d00b635f02b/CONVERGENCE.md)

이번 미니 실습의 산출물은 정의 v1·v2, 수정 이유, 새 자료에서의 확인 결과를 담은 카드 한 장입니다. 수정할 근거가 없으면 유지한 이유를 기록합니다. 이 카드에서 2주차에 필요한 대상·속성·관계 설계를 이어갑니다.

## 이번 주의 작은 결과

완성할 것은 거대한 그래프가 아니라, 내가 관리할 도메인 설명과 출처가 보이는 LLM Wiki v1입니다. 질문 3개와 적용 전 답변을 보존하고, 정리 후 어떤 근거를 더 잘 찾았는지 확인합니다. Jev를 썼다면 실제 실행과 오프라인 연습을 구분합니다.

다음 주에도 같은 질문을 계속 써야 구조를 바꾼 효과를 확인할 수 있습니다. 잘 나온 답만 골라 새 질문으로 바꾸지 않고, 틀리거나 보류된 질문도 사례에 남기겠습니다.