# Jev의 지식베이스·온톨로지 적용 사례와 AKM 결합안

조사일: 2026-09-29, 한국시간. **GitHub의 원저자 코드·실험 기록을 주 근거로 삼고 X 게시물은 보충**했다. 영어 원문은 핵심 의미를 한국어로 옮겨 요약했다. 외부 프로젝트의 수치는 작성자가 공개한 결과이며, 이번 조사에서 모델을 다시 호출해 재현한 결과가 아니다.

결론은 **AKM에 보존한 근거를 바탕으로, 온톨로지가 판단 기준을 제공하고 Jev가 반복되는 좁은 판단을 맡는 구성**이다. 가장 먼저 시험할 지점은 검색 후보 선별이다. 다음은 개념 별칭·중복과 관계 후보 검토이며, 온톨로지 자동 수정은 독립 평가를 갖춘 뒤 검토할 단계다.

## 1. 세 요소는 어떤 역할을 맡는가

| 요소 | 역할 | 예시 |
|---|---|---|
| AKM | 원문·설명·프로젝트 맥락·절차·판정 이력의 보존과 운영 | 어느 자료와 버전에서 나온 설명인지, 누가 검토했는지 |
| 온톨로지 | 개념의 종류·정의·관계·적용 조건을 명시 | 도구와 기법 구분, 같은 개념의 별칭, `uses`와 `requires`의 차이 |
| Jev | 제공된 근거와 선택지 안에서 의미를 판별 | 질문과 관련 있는 절인가, 같은 개체인가, 제안 관계를 뒷받침하는가 |
| 코드·검증기 | 정확한 규칙과 실행 통제 | ID·버전·날짜·해시·출처 검사, 타입과 관계 제약 검사 |
| 사람·주 모델 | 설명 작성과 중요한 변경 검토 | 새로운 개념 정의, 모호한 경계 해결, 최종 정본 집필 |

Jev는 TypeSafe의 텍스트 입력 결정 모델이다. `Choice`는 선택지 분류, `Noul`은 명제에 대한 0~1 판단값, `Score`는 정의한 척도에 따른 판단을 제공한다. 새 설명이나 온톨로지 본문을 작성하는 역할은 생성 모델이 맡는다. 조사 시 공식 모델은 `jev-1.13.0`, 입력 100만 토큰당 $0.042, 출력 무료다. 이미지·음성·영상은 직접 입력할 수 없다. [공식 모델 사양](https://docs.typesafe.ai/models), [공식 한계 설명](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

분류체계는 온톨로지의 일부가 될 수 있지만, 분류 트리 하나가 관계·공리·추론까지 갖춘 온톨로지 전체를 뜻하지는 않는다. 아래 사례도 문서 분류, 개체 연결, 그래프 탐색, 형식적 추론을 구분해서 읽어야 한다.

## 2. GitHub 사례 번역 요약

### A. kb-jev — 원문과 판단 기록을 보존하는 Markdown 지식베이스

**원문 요지:** 문서를 가져와 Jev로 주제를 분류하고, 애매한 결과를 검토·교정하며, 원문은 그대로 검색할 수 있게 한다. 원문 바이트와 SHA-256을 보존하고 분류체계·질문·모델·확률·사용량·시간을 판정과 연결한다. Obsidian에서 열 수 있다. [GitHub](https://github.com/robebots/kb-jev), [README 원문](https://raw.githubusercontent.com/robebots/kb-jev/main/README.md)

`src/classification.ts`에는 낮은 선택 확률, 1·2위 차이가 작은 경우, `other`, 모의 제공자를 검토 대상으로 보내는 코드가 있다. `docs/architecture.md`는 사람의 교정을 정확한 원문·판정·분류체계 버전에 묶는다. [분류 코드](https://github.com/robebots/kb-jev/blob/a91e4833f9073e8936a8aa59968c9e084f4666c3/src/classification.ts), [구조와 한계](https://github.com/robebots/kb-jev/blob/a91e4833f9073e8936a8aa59968c9e084f4666c3/docs/architecture.md)

**효과와 한계:** 출처 추적·교정·재평가 설계의 참고 사례다. 초기 프로토타입이며 공개 테스트와 데모는 오프라인 모의 분류다. 검색 순위는 분류 결과를 사용하지 않으므로, 이 버전에서 Jev의 검색 성능 개선은 측정되지 않았다. 이를 실서비스 정확도나 검색 향상 사례로 소개하면 안 된다.

**AKM 적용:** 기존 원문과 가이드북을 유지하면서 판정 기록을 부속 데이터로 연결한다. 분류 실패나 보류 때문에 원문이 검색에서 사라지지 않게 하는 방식이 특히 유용하다. `.kb` 구조를 그대로 복제할 필요는 없다.

### B. Jev_Ontology — 분류 실패를 온톨로지 수정 후보로 바꾸는 실험

**원문 요지:** LLM이 고객 문의 분류체계를 만들고, Jev가 각 문의를 하위 분류로 내려가며 판정한다. 낮은 확신도와 가까운 후보 점수를 모아 정의의 빈틈을 찾고, LLM이 분류체계를 수정한 뒤 다시 평가한다. 공개 기록은 고유 티켓 78개·분류 86건이다. [GitHub](https://github.com/dagfinndybvig/Jev_Ontology)

**관찰한 효과:** 중복 청구 문의가 기존 분류 사이에 걸리는 문제를 발견하고 `WrongfulCharge`를 추가했다. 같은 입력을 다시 평가했을 때 모델의 확신도가 상승했다. 이는 분류 경계 검토의 유용한 신호다.

**핵심 한계:** 별도 실험은 36개 수정용·16개 평가용으로 나눴다. 평가용 평균 확신도 상승은 0.004였고, 같은 조건의 반복 실행 범위 0.0045 안이었다. 새 자료에 대한 개선이 입증되지 않았다. 또한 확신도는 정답률이 아니다. [홀드아웃 실험 원문](https://github.com/dagfinndybvig/Jev_Ontology/blob/51311b3dd12b0ef0d8c0fb913ae56d00b635f02b/CONVERGENCE.md)

**AKM 적용:** 자주 보류되는 개념쌍을 모아 별칭·정의·분류 경계의 검토 후보로 쓸 수 있다. 확신도를 높이려고 정의를 넓히는 자동 수정은 피하고, 수정에 쓰지 않은 별도 자료로 정확도와 회귀를 확인한다. 이 프로젝트의 출발점은 분류 트리이며 OWL 추론기 구현 사례는 아니다.

### C. 같은 저장소의 Images — 이미지 설명과 온톨로지 분류의 분업

**원문 요지:** 대학 도서관 이미지 분류를 목표로, Pixtral이 이미지를 텍스트로 설명하고 Jev가 그 설명을 다섯 속성으로 분류한다. 불확실한 항목은 사람 검토로 보낸다. 실제 도서관 컬렉션 적용은 목표이며, 공개 자료를 이용한 대체 실험을 진행했다. [Images 프로젝트](https://github.com/dagfinndybvig/Jev_Ontology/tree/main/Images)

**작성자 결과:** 고정한 파이프라인으로 Smithsonian 자료를 평가해 사람 검토를 거친 140개 레코드에서 속성 판정 합산 일치도 97.0~97.5%를 보고했다. 이미지 전체 정답률이 아니라 실행당 610개 속성 판정의 합산 수치다. [재평가 결과](https://github.com/dagfinndybvig/Jev_Ontology/blob/51311b3dd12b0ef0d8c0fb913ae56d00b635f02b/Images/REPLICATION_RESULTS.md)

**수치 해석 주의:** 사람 검토가 실행 뒤 이뤄진 절차 변경과 1인 검토가 명시돼 있다. 보고서의 미검토 오분류 7~9%는 전체 140개가 분모다. 표의 건수로 미검토 항목만 분모에 두면 각각 10/115, 12/115, 12/119, 즉 약 8.7~10.4%다. 97%를 무인 자동처리 정확도로 읽으면 안 된다.

**AKM 적용:** 미디어아트 레퍼런스의 이미지·영상 설명을 기존 도구·재료·기법 개념에 연결할 때 참고할 수 있다. 인식 모델의 설명 오류와 Jev의 분류 오류를 따로 평가하고, 인식 비용도 전체 비용에 포함한다.

### D. Jev × Neo4j entity resolution — 애매한 개체쌍만 큰 모델로 보내기

**원문 요지:** Neo4j가 비교할 연락처 후보쌍을 줄이고, Jev가 같은 사람인지 판단하며, 애매한 쌍만 Opus에 재질문한다. 코드·원시 결과·집계 파일을 공개했다. [GitHub](https://github.com/Kervin-Hu-Neo4j/jev-neo4j-entity-resolution)

영어 합성 연락처 703개·실제 인물 330명에서 후보 1,822쌍을 평가했다. 아래 값은 공개 `results/summary.json`을 직접 읽은 결과다. F1은 후보쌍 판정, ARI는 최종 군집의 정답 일치 지표다.

| 방식 | F1 | 군집 ARI | 중앙값 / p95 | 전체 모델 호출 비용 |
|---|---:|---:|---:|---:|
| Jev | 0.9425 | 0.8882 | 368 / 470ms | $0.0330 |
| Opus | 0.9671 | 0.9027 | 2,003 / 3,468ms | $7.1390 |
| Jev + 애매한 쌍만 Opus | 0.9716 | 0.9027 | 376 / 3,427ms | $1.2349 |

[공개 집계 파일](https://github.com/Kervin-Hu-Neo4j/jev-neo4j-entity-resolution/blob/37184c2638e6d94c974989a79447867d48e27a1b/results/summary.json)

194쌍, 약 10.6%만 큰 모델에 넘겼다. 비용 비율은 공개 합계로 계산하면 17.3%, 절감률은 82.7%다. 중앙값은 빨라졌지만 p95는 Opus와 비슷하다. 후보 생성 단계가 놓친 정답 약 5%는 쌍별 F1에 포함되지 않는다. 합성 영어 데이터의 결과를 한국어 AKM에 그대로 적용할 수 없다. [작성자 방법론과 한계](https://medium.com/neo4j/i-tested-jev-on-entity-resolution-e7249f219ca6)

**AKM 적용:** 용어·별칭·버전의 동일성 판단을 먼저 Jev가 돕고 어려운 경우에만 주 모델이 전문을 읽는 구성이다. 문서를 한 가이드에 묶는 판단과 개체를 하나로 합치는 판단은 반드시 분리한다.

### E. neo4jev — 실제 존재하는 관계 중 다음 탐색 경로 선택

**원문 요지:** Neo4j에서 현재 노드의 관계 후보를 가져와 Jev의 `Choice`로 다음 이동을 고르고 `Noul`로 목표 도달을 판정한다. 경로별 분기를 유지하는 beam search와 Streamlit 화면을 제공한다. [GitHub](https://github.com/jexp/neo4jev)

`navigator.py`에서 호출 수·깊이 제한, 방문 집합, 정확한 목표 ID 비교, 관계 후보 매핑을 확인했다. 읽은 코드는 경로 점수를 로그확률의 합으로 정렬한다. 이는 곱셈의 수치 문제를 줄이지만, 그 자체로 경로 길이에 따른 편향까지 없애지는 않는다. [탐색 코드](https://github.com/jexp/neo4jev/blob/d157bbe496eb91813475156942bef1c6badfb342/src/neo4jev/navigator.py)

**효과와 한계:** 모델이 존재하지 않는 관계를 새로 써내는 대신, DB가 제공한 선택지에서 탐색하게 한다. 하지만 적절한 경로 선택과 완전한 탐색은 보장되지 않는다. 작성자는 모호한 목표의 완료 판정과 입력 품질을 약점으로 설명한다. 저장소에는 기본 임베딩이 의미 검색용이 아니라는 제한과 API 실패 시 모의 응답 표시도 있다. 정량 성능 비교는 확인하지 못했다. [작성자 설명](https://neo4j.com/blog/genai/navigating-a-neo4j-knowledge-graph-with-jev/)

**AKM 적용:** 이미 검토한 관계 인덱스에서 다음에 읽을 근거를 고르는 데 활용할 수 있다. 링크를 따라갔다는 사실과 관계의 내용이 참이라는 사실은 별도다.

## 3. 공식 예제로 보완되는 검색 적용 근거

GitHub 사례에 더해 공식 재정렬 실험은 문서 3,565개에서 질의 40개의 BM25 후보를 각각 30개씩 고른 뒤 Jev로 순위를 다시 매겼다. 정답이 1위에 놓이는 비율은 5%→18%, 10위 안에 드는 비율은 38%→62%였다. 1,200호출의 비용은 $0.0645로 보고됐다. 처음 후보 30개 안에는 모든 질의의 정답이 있었으므로 후보 생성의 실패를 해결한 실험은 아니다. 모델도 `jev-1.12` 기반이다. [공식 재정렬 실험](https://docs.typesafe.ai/cookbooks/rerank_typesafe)

별도 RAG 예제는 검색한 절을 관련성·답변 근거·질문 전제와의 충돌·유도 지시 여부로 평가하고 근거와 반론을 따로 전달한다. AKM에서는 단어가 비슷한 자료를 줄이면서 질문의 잘못된 전제를 고칠 근거를 보존하는 설계로 옮길 수 있다. 이 예제의 임계값을 한국어 AKM의 검증된 값으로 가져오지는 않는다. [공식 RAG 예제](https://docs.typesafe.ai/cookbooks/classifying_rag_passages)

## 4. X 작성자 게시물은 보충 근거로만 사용

Aside의 읽기 전용 검색과 원문 열기로 두 게시물을 확인했다. 지정 GitHub 프로젝트와 직접 연결된 원저자 X 글은 제한 검색에서 확보하지 못했다. 검색 결과가 없다는 것이 게시물 부재를 뜻하지는 않는다.

| 작성자·날짜 | 번역 요약 | 근거의 범위 |
|---|---|---|
| Hassan / @nutlope, 2026-09-17 | AI 논문 1,018편을 먼저 요약하고 제목·요약·24개 주제로 Jev 분류. 분류 $0.08, 요약 $3.99, 분류 지연 중앙값 256ms 보고 | 기존 분류 대체 전 평가 중. 정확도 공개 결과는 확인되지 않음. [X 원문](https://x.com/nutlope/status/2100426999546184123) |
| Kev Builds Apps, 한국시간 2026-09-22 | Apple Photos 접근, Claude 태깅, Obsidian 지식그래프를 연결해 클립 탐색에 Jev를 활용한다고 소개 | 비용·정확도·Jev 세부 역할은 미확인. [X 원문](https://x.com/kevbuildsapps/status/2102133939951280593) |

두 번째 사례를 Jev의 직접 이미지 인식 증거로 쓰면 안 된다. 전체 영상이나 비공개 구현은 검증하지 않았다.

## 5. AKM에는 이미 무엇이 도입되어 있는가

2026-09-26 기록상 공통 절차와 실제 호출 경로가 마련돼 있다. 조사 당시 연결 도구 목록도 확인했다. **연결 구현이 있다는 사실과 지식관리 효과가 측정됐다는 사실은 다르다.**

| 확인 항목 | 현재 근거 | 아직 입증하지 않은 것 |
|---|---|---|
| 목적별 연결 | `jev_tools`: 일반 도구 선택·반복 읽기. `jev_akm`: 이미 읽은 발췌의 관련성·개체·관계·통합 방식 판단 | 모든 작업에서 에이전트가 적절하게 호출하는지 |
| 문서 통합 파일럿 | 9/22 임시 기준과 10/10 일치, 입력 7,584토큰, 호출 중앙값 228ms | 독립 정답 기준, 통합 완성본의 품질, 비용·시간 절감 |
| 한국어 도구 선택 시험 | 9/19 실사용형 24사례에서 2회 모두 23/24. 브라우저 대체 경로 누락 반복 | 실서비스 완료율·안전성 보증 |
| 호출 구현 검증 | 9/26 기록에 오프라인 회귀 23개 통과, 실제 API·도구 목록·비공개 입력 거부 검사 | 온톨로지 품질이나 실제 검색 성능 향상 |

스터디장 내부 실행 기록을 검토한 요약이다. 독립 공개 벤치마크가 아니며 이번 조사에서 재실행하지 않았다. 스터디멤버 설치 요건이나 보장된 성능으로 사용하지 않는다.

현재 `jev_akm`은 최대 8개·각 2,400자 발췌를 받으며 `auto_apply: false`다. 파일 탐색·변경, 자동 문서 병합, 관계 추가는 하지 않는다. 공개·비민감 발췌만 전송하며 영구 판단 캐시는 아직 구현돼 있지 않다. 이 문서는 공통 절차를 대체하지 않는다.

## 6. 온톨로지 + AKM + Jev를 함께 적용하는 방법

### 먼저 답할 질문을 고른다

추천하는 첫 범위는 미디어아트의 **도구·기법·재료**다. 이미 있는 자료를 이용해 다음과 같은 질문을 평가한다.

1. 이 조건에서 참고할 가이드와 근거는 무엇인가?
2. 한글·영문 표현이 같은 개념인가, 관련된 별개 개념인가?
3. 이 도구가 바뀌면 어떤 기법 설명을 다시 확인해야 하는가?
4. 이 관계는 원문이 뒷받침하는가, 단지 같은 문서에 등장하는가?

AKM의 `akmLayer`는 문서의 운영 역할이다. `knowledge`, `procedure` 같은 레이어와 도메인의 `Tool`, `Technique`, `Material` 분류는 별도 축으로 유지한다. 같은 자료에 두 축의 메타데이터가 공존할 수 있다.

### 최소 개념·관계부터 명시한다

아래는 새로 적용할 때의 설계 예시이며 현재 배포된 스키마라고 주장하지 않는다. 실제 도입에서는 기존 용어·ID·관계 계약과 먼저 대조한다.

| 항목 | 최소 정의 |
|---|---|
| 개념 | `Tool`, `Technique`, `Material`, `Task`, `Evidence` |
| 개념 ID | 문서 제목이 바뀌어도 유지되는 식별자 |
| 라벨 | 대표 이름과 언어별 별칭. 같은 이름만으로 같은 ID에 합치지 않음 |
| 관계 | `uses`, `requires`, `part_of`, `alternative_to`, `supported_by` 등 기존 허용 관계 재사용 |
| 관계의 근거 | 원문 파일·절, 입력 해시, 적용 버전·조건, 검토 상태 |
| 판정 이력 | 질문·온톨로지·모델 버전, 후보, 결과, 보류 사유, 사용량·시간 |

`uses`는 어떤 사용 사례에서 사용하는 관계이고 `requires`는 명시된 조건에서 필수라는 더 강한 주장이다. `related`나 위키링크를 자동으로 `requires`로 바꾸지 않는다. `sameAs`는 엄격한 동일성에만 사용하고, 단순 별칭·유사성·상하위 유형을 분리한다.

### 읽기와 지식 갱신을 연결한다

```text
AKM 원문·가이드·맥락 → 검색 후보
온톨로지 정의·관계·조건 → Jev 후보 판단
→ 필수 근거·반론·보류 보존 → 원문 확인과 답변
모호한 판단 → 정의 수정안 → 별도 자료 평가·제약 검사
→ 검토된 변경만 AKM 정본·온톨로지에 반영
```

검색 단계에서는 Jev가 전체 볼트를 읽지 않게 한다. qmd가 이미 확보한 짧은 후보만 평가한다. 기존 qmd의 재정렬과 기능이 겹치면 추가 단계의 비용까지 비교하고, 근거가 충분한 정확한 경로 조회는 곧바로 읽는다.

갱신 단계에서는 Jev의 결과를 후보 판정으로 남긴다. 제약 검사와 검토를 통과한 경우에만 원문을 근거로 관계를 채택한다. RDF를 사용하는 경우 SHACL은 그래프가 정해진 제약을 만족하는지 검사하고, OWL 추론기는 명시한 공리의 논리적 귀결을 다룬다. 이 둘도 원문 주장의 사실성을 독립적으로 보증하지 않는다. [W3C SHACL](https://www.w3.org/TR/shacl/), [W3C OWL 2 Primer](https://www.w3.org/TR/owl2-primer/)

처음에는 Markdown 정본과 작은 관계 인덱스로 시작할 수 있다. 관계가 수많은 경로 질의에 쓰이고 기존 인덱스가 감당하기 어려울 때 그래프 DB를 검토한다. DB를 바꾸는 것보다 개념 정의와 근거 연결을 먼저 정하는 것이 이 적용안의 핵심이다.

### 한 작업을 따라 본 예시

아래는 방식 설명용 가상 예시이며 이번에 실행한 결과나 투사 재료의 기술적 권장안이 아니다.

“유리와 천에 후면 투사할 때 비교할 자료를 찾아줘”라는 질문을 받았다고 하자.

- qmd가 관련 가이드 절과 공식 출처를 찾는다.
- 온톨로지는 `유리`, `천`을 별개 재료, `후면 투사`를 기법으로 구분한다.
- Jev는 질문의 비교 근거·조건을 제한하는 반론·관련 없는 절·추가 확인 대상을 분류한다.
- `Projection Mapping`과 `프로젝션 매핑`은 정의가 맞으면 같은 개념의 별칭 후보가 되지만, `후면 투사`를 같은 개체로 합치지는 않는다.
- 유리와 천의 자료가 같은 비교 가이드에 들어가도 두 재료 노드는 유지한다.
- 어떤 관계를 채택할지는 정확한 재료·코팅·설치 조건과 출처를 읽고 결정한다. 근거가 없으면 `INSUFFICIENT`로 남긴다.

이렇게 하면 검색 결과를 줄이면서도 비교에 필요한 차이를 보존할 수 있다. 이는 설계상의 기대 효과이며 성능 측정 결과는 아니다.

## 7. 도입 효과를 어떻게 확인할 것인가

| 기대 효과 | 실제로 측정할 값 | 함께 봐야 할 손실 |
|---|---|---|
| 주 모델이 읽을 본문 감소 | 같은 질문의 전달 토큰·전문 읽기 횟수 | 필수 근거·반론 누락 |
| 개념 중복과 별칭 정리 | 별칭 회수율·개체쌍 정밀도 | 잘못된 동일 개체 병합 |
| 관계의 근거 보강 | 출처가 연결된 유효 관계 비율 | 동시 출현을 인과·필수 관계로 오인 |
| 유지보수 범위 축소 | 변경 한 건당 다시 읽은 문서 수·검토 시간 | 영향을 받은 문서 누락 |
| 비용 감소 | Jev·주 모델·검색·인식·재시도·사람 검토를 합한 비용 | 보류 증가·재작업·p95 지연 |
| 온톨로지 경계 개선 | 수정용과 분리한 평가셋의 정확도·회귀 | 확신도 상승만으로 개선을 주장 |

가장 직접적인 외부 비용 근거는 사례 D의 제한적 재검토 방식이다. AKM에서는 작은 기존 파일럿만 있으므로 “82.7% 절감”을 AKM의 성과로 옮겨 적을 수 없다.

계산 예시로, 질문을 포함해 판정 1회당 청구 입력이 2,000토큰이고 총 1,000회면 Jev 입력 비용은 **$0.084**다. 공식 단가에 대입한 가정이며 검색·입력 준비·요약·이미지 설명·주 모델 재검토 비용은 제외했다. Jev API 비용과 주 모델의 계정 사용량은 따로 계량한다.

`전체 개선 = 줄어든 주 모델 읽기·판단 비용 − 추가된 Jev·전처리·재검토 비용`

자료쌍의 수, 날짜·버전 비교, 비용 계산은 코드가 맡는다. 선택 확률, 응답의 `confidence`, 실제 정답률은 서로 다른 값으로 보존한다. 여러 단계의 확률을 곱한 값도 전체 판단의 검증된 정확도로 해석하지 않는다.

## 8. AKM 권장 적용 순서

다음은 제안이다. 새 구현·크론·자동 병합을 이번 조사에서 가동하지 않았다.

1. **기존 경로 기준선 고정.** 한 도메인의 공개·비민감 자료로 실제 검색 질문과 사람 기준 근거를 확보한다. qmd의 현재 검색·재정렬 결과를 그대로 기준선으로 삼는다.
2. **검색 선별 관찰 평가.** 예를 들어 30개 질문으로 설계를 조정하고, 겹치지 않는 별도 30개로 확인한다. 처음에는 원래 검색 결과를 보존한 채 Jev 판단만 기록한다. 누락·전달 토큰·지연·총비용을 비교한다.
3. **별칭·개체·관계 평가.** 예를 들어 별칭·버전·하위유형·동명이의어를 포함한 100쌍과 관계 50건을 따로 평가한다. 규모는 출발점 제안일 뿐 안전성을 보증하는 표본 수가 아니다.
4. **검토 대기열 연결.** 높은 확률의 오답도 표본 검수하며, 낮은 확률만 검수하지 않는다. 원문 해시·모델·질문·온톨로지가 바뀐 판정은 재평가 대상으로 둔다. 캐시 도입은 별도 구현 사항이다.
5. **관계 탐색과 수정 루프 확장.** 필요한 질문에만 경로 탐색을 붙이고 호출 수·깊이·방문 집합을 제한한다. 반복 보류에서 정의 수정안을 만들되, 분리된 평가와 사람이 읽을 정본의 품질이 개선된 경우에만 채택한다.

첫 채택 기준은 “호출이 빠르다”가 아니라 **필수 근거를 보존하면서 실제 전체 비용이나 검토 시간이 줄었는가**다. 기존 경로보다 도움이 안 되는 질문은 Jev를 건너뛴다.

## 9. 확인 범위와 다시 볼 위치

공개 저장소의 README, 아래 결과·구현 파일, 공식 문서를 읽었다. 저장소 코드를 설치·실행하지 않았고 새 Jev API 실험도 하지 않았다. GitHub HTML 조회가 실패한 `kb-jev`는 GitHub 공개 API와 원본 README·코드의 HTTP 조회로 확인했다. 원저자 수치가 있는 사례, 기능 구현만 있는 사례, 제안 단계를 구분했다.

| 저장소 | 조회 시 Git tree가 보고한 커밋 | 직접 확인한 핵심 파일 |
|---|---|---|
| `robebots/kb-jev` | `a91e4833f9073e8936a8aa59968c9e084f4666c3` | `README.md`, `docs/architecture.md`, `src/classification.ts` |
| `dagfinndybvig/Jev_Ontology` | `51311b3dd12b0ef0d8c0fb913ae56d00b635f02b` | `README.md`, `CONVERGENCE.md`, `Images/README.md`, `Images/REPLICATION_RESULTS.md` |
| `Kervin-Hu-Neo4j/jev-neo4j-entity-resolution` | `37184c2638e6d94c974989a79447867d48e27a1b` | `README.md`, `results/summary.json` |
| `jexp/neo4jev` | `d157bbe496eb91813475156942bef1c6badfb342` | `README.md`, `src/neo4jev/navigator.py` |

X 보충 조사는 관련 키워드의 제한 검색과 위 두 게시물의 원문 확인으로 수행했다.

적용 시 자신의 AKM 설치판 지침과 검토 절차를 우선한다. 이 문서는 조사·교육 자료이며 자동 변경 지침이 아니다.