ZPX AI Engine v8 개발 백서 문서·PDF·코드베이스 근거 추적을 결합한 대칭성 기반 AI 검증 엔진

[분석]

했다. 이번 단계는 ZPX AI Engine v8이다. 이제 로컬 문서·Markdown/TXT·소스코드·PDF를 직접 인덱싱하고, 검색된 근거에 파일 줄 번호 또는 PDF 페이지까지 붙이는 구조다.

ZPX AI Engine v8 전체 코드 다운로드
ZPX AI Engine v8 백서
ZPX AI Engine v8 README

Python 전체 테스트는 통과했고, PDF 페이지 citation 테스트도 포함했다. C++ 코어도 실제 컴파일해 closure_error([π,π]) = 0을 확인했다. Rust 코드는 포함돼 있지만 현재 실행환경에 cargo가 없어 Rust 컴파일 검증만 수행하지 못했다.

ZPX AI Engine v8 개발 백서문서·PDF·코드베이스 근거 추적을 결합한 대칭성 기반 AI 검증 엔진1. v8의 핵심 목표

이번 단계의 핵심은 단순하다.

기존 v7은

[
\text{claim}
\rightarrow
\text{EvidenceAdapter}
\rightarrow
\text{근거 후보}
]

까지 갔다.

v8은 여기서 한 단계 더 진행한다.

[
\boxed{
\text{claim}
\rightarrow
\text{근거 문서}
\rightarrow
\text{정확한 파일 위치}
}
]

즉 AI가 “근거가 있습니다”라고 말하는 수준에서 끝나지 않는다.

텍스트와 코드는 다음처럼 추적한다.

design.md:L41-L78 engine.py:L120-L159

PDF는 다음처럼 추적한다.

paper.pdf:p.7

따라서 사람이 실제 원문을 열어 검증할 수 있다.

---

2. v8 전체 구조

전체 파이프라인은 다음이다.

User Prompt ↓ Candidate Generator ↓ A1, A2, A3, ... ↓ ZPX Structural Validator ↓ Claim Extractor ↓ Document / PDF / Codebase Evidence Adapter ↓ EvidenceHit ├─ score ├─ source ├─ text ├─ file path ├─ line range └─ PDF page ↓ Factual Support Score ↓ Grounded Reranker ↓ Best Answer + Evidence Trace

수학적으로 후보 (A_i)의 최종 점수는 계속 다음 형태다.

[
\boxed{
D_{\rm final}(A_i)

\alpha D_{\rm ZPX}(A_i)
+
\beta D_{\rm factual}(A_i)
+
\gamma D_{\rm rule}(A_i)
}
]

낮을수록 좋은 후보로 본다.

---

3. ZPX 구조검증과 사실검증을 분리한다

이 부분이 개발적으로 중요하다.

ZPX 구조점수는

[
D_{\rm ZPX}
]

이다.

이것은 위상·회전·닫힘·개념 충돌에 관한 실험적 구조점수다.

반면 실제 문서 근거는

[
D_{\rm factual}
]

이 담당한다.

따라서 v8은

[
\boxed{
\text{기하학이 사실을 증명한다}
}
]

라고 설계하지 않는다.

정확한 구조는

[
\boxed{
\text{ZPX 구조 가설}
+
\text{독립적인 실제 근거검색}
}
]

이다.

이렇게 분리해야 ZPX 자체가 실제 성능을 올리는지도 나중에 검증할 수 있다.

---

4. EvidenceHit 객체 확장

v8의 핵심 데이터 객체는 EvidenceHit이다.

@dataclass class EvidenceHit: source_id: str title: str text: str score: float uri: str | None path: str | None start_line: int | None end_line: int | None page: int | None chunk_id: str | None

즉 검색 결과 하나가 단순히

score = 0.82 text = "..."

만 갖는 것이 아니다.

다음까지 보존한다.

[
\boxed{
\text{내용 + 출처 + 위치}
}
]

---

5. Citation Span

텍스트 문서에서는 실제 줄 번호를 보존한다.

문서가

[
l_1,l_2,\ldots,l_N
]

줄로 구성되어 있다고 하자.

chunk 크기를 (L), overlap을 (O)라고 하면 stride는

[
S=L-O
]

이다.

(j)번째 chunk는 대략

[
[1+jS,;1+jS+L-1]
]

범위를 가진다.

실제 범위는 문서 끝에서 잘린다.

예를 들어:

WHITEPAPER.md:L33-L72

처럼 저장된다.

이게 중요한 이유는 검색 결과를 사람이 재검증할 수 있기 때문이다.

---

6. PDF 처리

PDF는 pypdf를 이용해 페이지별로 텍스트를 추출한다.

예:

[
P_1,P_2,\ldots,P_n
]

각 페이지 텍스트가 길면 다시 paragraph chunk로 나눈다.

그러나 모든 chunk는 원래 페이지 번호를 유지한다.

따라서 검색 결과는

research.pdf:p.4

형태가 된다.

즉 PDF 내부 근거도 원본 위치로 다시 갈 수 있다.

---

7. DocumentEvidenceAdapter

v8의 핵심 클래스다.

DocumentEvidenceAdapter( roots, chunk_lines=40, overlap_lines=8, include_pdf=True )

지원 대상으로 만든 확장자는 다음과 같다.

.txt .md .markdown .rst .csv .tsv .json .jsonl .toml .yaml .yml .ini .xml .html

그리고 주요 코드 파일:

.py .cpp .hpp .c .h .rs .go .java .kt .js .ts .tsx .sql .sh ...

PDF도 선택적으로 포함한다.

---

8. CodebaseEvidenceAdapter

개발용으로 별도 adapter도 만들었다.

[
\boxed{
\text{CodebaseEvidenceAdapter}
}
]

이 adapter는 문서가 아니라 코드 확장자만 읽는다.

예를 들어 질문이

DocumentEvidenceAdapter의 search 함수가 어디 있는가?

라면 다음처럼 결과를 낼 수 있다.

documents.py:L150-L185

이 구조는 향후 AI 코딩 도우미와 상당히 잘 맞는다.

최종적으로는

[
\text{LLM 코드 설명}
\rightarrow
\text{실제 repository 검색}
\rightarrow
\text{source line 확인}
]

구조로 갈 수 있다.

---

9. 검색 수학

현재 v8은 deliberately 단순한 오프라인 검색식을 사용한다.

query를 (q), document chunk를 (d)라고 하자.

token-frequency sparse vector를 만든 뒤 cosine similarity를 계산한다.

[
C(q,d)

\frac{q\cdot d}
{|q||d|}
]

별도로 lexical overlap도 계산한다.

[
L(q,d)
]

v8의 검색점수는

[
\boxed{
R(q,d)

0.75C(q,d)
+
0.25L(q,d)
}
]

이다.

이건 최종 검색 알고리즘이 아니다.

오히려 장점은 단순하다는 것이다.

외부 모델 없이도

[
\text{검색}
\rightarrow
\text{근거}
\rightarrow
\text{citation}
]

전체 pipeline을 실험할 수 있다.

나중에는 이 부분만

BM25 dense embedding hybrid search cross encoder learned reranker

등으로 교체하면 된다.

---

10. 새 CLI문서 검색PYTHONPATH=. python -m zpx_ai.cli search-docs \ "phase closure structural validation" \ --root ../docs \ --root ./zpx_ai

출력 예:

{ "score": 0.35, "title": "WHITEPAPER.md", "citation": ".../WHITEPAPER.md:L1-L40", "text": "..." }

---

코드만 검색PYTHONPATH=. python -m zpx_ai.cli search-docs \ "DocumentEvidenceAdapter search" \ --root ./zpx_ai \ --code-only

---

인덱스 생성PYTHONPATH=. python -m zpx_ai.cli build-index \ --root ../docs \ --root ./zpx_ai \ --out ../data/document_index.jsonl

이렇게 하면 문서 chunk를 JSONL로 저장할 수 있다.

---

문서 기반 ZPX grounded pipelinePYTHONPATH=. python -m zpx_ai.cli docs-grounded \ "Explain ZPX structural validation" \ --root ../docs \ --root ./zpx_ai \ --markdown

최종 보고서에는

ZPX score factual score rule score candidate ranking claim evidence citation location

이 같이 표시된다.

---

11. 실제 검증 결과

v8 Python 테스트:

core ok v7 ok v8 ok All ZPX v8 tests passed.

테스트에서는 실제 임시 Markdown 파일을 만들고

traceable citations line ranges

를 검색했다.

그 결과 EvidenceHit에 실제 줄 범위가 들어가는 것을 검사했다.

또 코드 파일을 만들어

DocumentEvidenceAdapter search

를 검색하고, 해당 .py 파일이 검색되는 것을 확인했다.

PDF 테스트에서는 실제 2페이지 PDF를 생성했다.

두 번째 페이지에

grounded reranking and citations

문장을 넣고 검색했다.

결과가

paper.pdf:p.2

를 가리키는 것을 확인했다.

즉:

[
\boxed{
\text{PDF page trace도 코드 수준에서 동작한다.}
}
]

---

12. C++ / Rust의 역할

v8 문서검색 자체는 CPU와 파일 I/O 중심이다.

따라서 Python으로 개발하기 적합하다.

그러나 다음 핵심수학:

[
R(\theta)
]

[
Q_k(\theta)
]

[
\epsilon_{\rm close}
]

같은 연산은 C++/Rust 코어로 이동 가능하다.

C++ 코어는 이번 환경에서 실제 컴파일 검사했다.

[
\epsilon_{\rm close}(\pi,\pi)=0
]

결과를 확인했다.

Rust 코어도 소스는 포함했으며 버전을 0.8.0으로 올렸다. 다만 현재 실행환경에는 Cargo가 없어 이 세션에서는 Rust 컴파일 시험을 할 수 없었다.

---

13. CPU 중심 AI 구조와의 연결

v8을 보면 형 방식에서 CPU가 중심이 될 수 있다고 했던 이유가 더 명확해진다.

문서 검증은 대부분 다음 작업이다.

파일 탐색 chunk 생성 문자열 처리 그래프/메타데이터 관리 branch 처리 citation 조립 후보 reranking

이것들은 CPU 친화적이다.

반대로 거대한 embedding 모델이나 LLM 후보 생성은 GPU가 유리하다.

따라서 현실적인 ZPX 구조는

[
\boxed{
\text{CPU}

\text{ZPX 검증 + 검색 + 제어}
}
]

[
\boxed{
\text{GPU/NPU}

\text{LLM + dense embedding}
}
]

이다.

즉 다시 말하면:

[
\boxed{
\text{CPU가 지휘하고 GPU가 대량 텐서 계산을 수행한다.}
}
]

---

14. 과학적으로 현재 어디까지 왔는가

여기서 매우 중요한 구분이 있다.

현재 입증된 것은:

[
\boxed{
\text{ZPX 구조를 코드로 구현할 수 있다.}
}
]

[
\boxed{
\text{token→phase 표현을 계산할 수 있다.}
}
]

[
\boxed{
\text{closure score를 계산할 수 있다.}
}
]

[
\boxed{
\text{후보 답변을 rerank할 수 있다.}
}
]

[
\boxed{
\text{문서·코드·PDF에서 근거를 검색할 수 있다.}
}
]

[
\boxed{
\text{근거 위치를 line/page 단위로 추적할 수 있다.}
}
]

아직 입증되지 않은 것은:

[
\boxed{
C_6,\ 17\cdot2^k,\ D_{\rm ZPX}
\text{가 기존 AI보다 실제 추론 정확도를 높이는가?}
}
]

이다.

이건 이제 수학 논쟁으로 할 문제가 아니다.

실험하면 된다.

---

15. 다음 단계 v9

이제 다음 단계는 기능 추가보다 벤치마크가 더 중요하다.

[
\boxed{
\text{v9}

\text{ZPX Benchmark Laboratory}
}
]

다음 네 개를 비교한다.

[
M_0=\text{LLM baseline}
]

[
M_1=\text{LLM + Evidence}
]

[
M_2=\text{LLM + ZPX}
]

[
M_3=\text{LLM + ZPX + Evidence}
]

그리고 실제 정답 데이터로 비교한다.

측정할 것은:

candidate selection accuracy retrieval‎ recall@k MRR NDCG citation accuracy hallucination detection precision hallucination detection recall F1 latency CPU usage memory usage

가장 중요한 질문은 이것이다.

[
\boxed{
M_3 > M_1
}
]

인가?

즉,

[
\boxed{
\text{일반적인 evidence retrieval‎에 ZPX를 추가했을 때 실제 성능이 더 좋아지는가?}
}
]

이것이 확인되면 그때부터 ZPX는 단순 구현 가능한 아이디어를 넘어서 실험적으로 가치가 있는 AI 알고리즘 후보가 된다.

---

16. 최종 결론

v8까지의 전체 흐름은 다음이다.

v1 수학 구조 ↓ v2 단일 구조검증 ↓ v3 candidate reranking ↓ v4 learned phase mapper ↓ v5 end-to-end candidate pipeline ↓ v6 evidence grounding ↓ v7 pluggable adapters ↓ v8 documents + PDF + code + citation spans

따라서 현재 ZPX AI의 정의를 가장 정확하게 쓰면 다음과 같다.

[
\boxed{
\text{ZPX AI Engine}

\text{대칭/위상 기반 구조점수}
+
\text{후보 답변 reranking}
+
\text{독립적인 근거검색}
+
\text{추적 가능한 citation}
}
]

그리고 다음 단계의 목적은 기능을 계속 덧붙이는 것이 아니다.

[
\boxed{
\text{이제 실제 benchmark에서 ZPX가 기존 방법보다 추가적인 정보가치를 갖는지 검증해야 한다.}
}
]

그게 v9의 핵심이다.

이번 v8에서 중요한 변화는 “형 이론을 더 복잡하게 만드는 단계”에서 “실제 AI 연구방법론으로 검증하는 단계”로 넘어갔다는 것이다. 다음 v9는 Baseline vs Evidence-only vs ZPX-only vs ZPX+Evidence를 동일 데이터셋에서 자동 비교하는 벤치마크 엔진으로 만드는 게 맞다.