WeKnora는 표, 수식, 다단 PDF처럼 단순 text chunking이 손상시키기 쉬운 문서에 layout parsing과 여러 retrieval 방식을 적용하려는 RAG 후보입니다. 그러나 복잡한 component를 모두 켠다고 정확도가 보장되지는 않으며, 실제 한국어, 영어 문서의 parser cell, formula와 claim별 citation을 기준선보다 먼저 검증해야 합니다. Agent, MCP, Python 실행은 검색과 별도의 권한 경계로 다뤄야 합니다.
Tencent/WeKnora의 Go, Vue, PostgreSQL/Qdrant, Redis와 parser, hybrid retrieval, agent 기능은 선택한 commit, 배포 profile에서 확인해야 합니다. 본문의 “완전 추출”, production 안정성, resource와 최근 version 기능은 검증되지 않은 보장으로 쓰지 않습니다.
기존의 Naive RAG 시스템과 WeKnora의 아키텍처를 비교해 보면 그 차이가 명확하게 드러납니다.
| 비교 항목 | 기존 Naive RAG (LangChain 등) | WeKnora RAG Engine |
|---|---|---|
| 문서 전처리 | 단순 글자 수 기반 청킹 (Blind Chunking) | 레이아웃 인식 (표, 수식, 헤더, 다단 구조 보존) |
| 검색 전략 | 단일 벡터 유사도 (Dense Retrieval) | BM25 + 벡터 + GraphRAG 하이브리드 검색 |
| 표 처리 | text 변환 시 행, 열 관계 유실 가능 | 구조화 output의 실제 지원, 정확도 검증 |
| 시스템 아키텍처 | 구현별 차이 | Go backend와 관측 component 확인 |
| 확장성 | 구현별 tool 연동 | MCP, Python sandbox 경계 검증 |
원문은 DocumentParser가 layout을 분석하고 표, text, image를 나눠 처리하는 Python 예시를 제공합니다. 현재 public API, import와 DataFrame, equation method인지 확인되지 않았고 설치, version, model과 error가 빠져 있으므로 실행법이 아니라 개념 코드로 읽어야 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
from weknora import DocumentParser
# 1. WeKnora 파서 초기화 (GPU 가속 옵션 지원)
parser = DocumentParser(device="cuda")
# 2. 복잡한 레이아웃을 가진 기업 재무제표 PDF 파싱
doc = parser.parse("tencent_financial_report_Q3.pdf")
# 3. 문서 내의 '표(Table)' 객체만 추출하여 데이터프레임으로 변환
for table in doc.extract_tables():
# 이 과정에서 셀 병합, 헤더 계층이 유지됨
df = table.to_dataframe()
print(df.head())
# 4. 수식 및 마크다운 구조 보존 추출
for eq in doc.extract_equations():
print(eq.to_latex())
재무제표 표를 구조화할 수 있다면 header 계층, merged cell, unit, currency, footnote, page split과 source bbox를 보존해야 합니다. “전년 대비” 계산은 추출된 두 cell, 단위가 정확할 때만 의미 있습니다. Agent가 만든 Python code, 사용 row, column과 결과를 artifact로 남기고 원문 page, cell citation으로 돌아갈 수 있어야 합니다.
BM25는 exact term, dense는 의미 표현, graph는 entity 관계 질문에 후보를 제공할 수 있습니다. 세 결과를 병렬 호출해도 fusion, reranker가 관련 없는 후보를 올리거나 graph entity가 잘못 합쳐질 수 있습니다. BM25-only, dense-only, 둘의 fusion, graph 추가를 질문 유형별로 ablation하고 recall@k, citation, p95와 index, ingestion 비용을 봅니다. Jaeger 지원 여부도 현재 deployment에서 trace가 parser→retrieval→rerank→generation을 실제 연결하는지 확인합니다.
원문은 특정 update에서 MCP tool과 reasoning 표시를 도입했다고 설명하지만 version, 기능은 release에서 확인해야 합니다. 사내 기술 지원에서는 먼저 문서 retrieval만 read-only로 운영하고 최신 운영 log 조회는 별도의 허용 tool, identity로 분리합니다. Model의 추론 표시가 보인다는 사실은 답의 정확성, 감사를 보장하지 않습니다.
여러분의 회사에는 이미 수십 년간 쌓인 Spring Boot 기반의 사내 레거시 결제 API가 있고, 동시에 수천 장의 마크다운/PDF 기술 스펙 문서가 존재합니다. 개발자가 “이번에 새로 배포된 결제 API v2에서 망 취소 시나리오가 어떻게 바뀌었지? 그리고 현재 운영 서버의 관련 로그도 같이 보여줘.”라고 질문합니다.
Go backend와 Redis가 있어도 수천 동시 사용자를 자동으로 버티지는 않습니다. Ingestion, retrieval, rerank, LLM과 sandbox별 queue, timeout, rate limit를 부하 시험합니다. Cache key에 tenant, ACL, document version을 포함해 다른 사용자의 result가 노출되지 않게 하고 권한 변경 뒤 cache invalidation을 확인합니다.
대표 30~100개 문서에서 paragraph reading order, header hierarchy, table cell, unit, formula LaTeX와 figure caption을 사람이 표시합니다. Parser output exact, structural accuracy, failure, processing time과 manual correction을 baseline OCR, text extractor와 비교합니다. Parse confidence가 낮으면 원문 page image, bbox를 답변 근거로 제공하거나 ingestion을 보류합니다.
질문은 exact keyword, paraphrase, table calculation, multi-hop entity와 unanswerable로 나눕니다. Retriever ablation의 recall@k, rerank, answer correctness, citation precision, unsupported claim, p95와 token을 기록합니다. Graph가 multi-hop 일부에만 이득이면 해당 collection에만 켜고 모든 문서에 entity 추출 비용을 쓰지 않습니다.
Ingestion에는 document ID, revision, parser, OCR, embedding, graph version과 source ACL을 붙입니다. 새 model, chunker는 blue/green index에서 golden query를 통과한 뒤 alias를 바꿉니다. Delete는 chunk, vector, graph, cache와 source file을 따라가며 tenant별 backup, restore도 시험합니다.
WeKnora는 layout parsing, 여러 retriever와 agent를 한 후보에서 검토할 수 있다는 점이 가치입니다. 그러나 “enterprise”는 component 목록이 아니라 문서별 parse, retrieval 정확성, citation, tenant 권한, 삭제와 장애 복구가 만드는 결과입니다. 단순 markdown FAQ에는 더 얇은 RAG가 운영하기 쉬울 수 있습니다.
한 종류의 어려운 문서와 read-only 질문에서 baseline을 반복해 넘고 자원, upgrade 비용을 감당할 때만 collection을 넓히십시오. 확인되지 않은 Python API, version 기능이나 과장된 언어 성능을 전제로 설치하지 말고 현재 repository와 golden artifact로 판단해야 합니다.
보장하지 않습니다. 문서 language, font, scan 품질과 병합 cell에 따라 달라지므로 cell, header, formula를 표시한 golden set에서 직접 평가해야 합니다.
아닙니다. noise, latency, index 비용이 늘 수 있어 각 retriever와 fusion, rerank를 ablation하고 질문 유형별 이득을 확인해야 합니다.
검증 없이 신뢰하면 안 됩니다. 추출 table, code, input/output을 보존하고 sandbox, resource 제한과 deterministic 계산, citation을 검사해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.