OpenCairn 첫 벤치마크 결과

OpenCairn을 만들면서 가장 조심해야겠다고 느낀 말이 있습니다. "RAG가 좋다", "에이전트가 좋다" 같은 말입니다.

듣기에는 그럴듯하지만, 실제로는 너무 쉽게 쓰이는 말입니다. 벡터 검색을 붙였다고 좋은 RAG가 되는 것도 아니고, LLM이 계획을 몇 줄 만들었다고 좋은 에이전트가 되는 것도 아닙니다. 저는 오히려 이 말을 빨리 쓰면 위험하다고 생각하게 됐습니다.

그래서 OpenCairn은 먼저 어떤 실패를 잡아야 하는지부터 정하고, 아주 작은 첫 baseline을 남겼습니다.

이번 결과는 거창한 점수가 아닙니다. DB를 새로 seed하지 않았고, LLM judge도 붙이지 않았고, production ingest 기본값이나 parser dependency도 바꾸지 않았습니다. 대신 권한 누수처럼 절대 깨지면 안 되는 경계와 agentic workflow fixture 구조를 처음으로 JSONL/Markdown report로 기록했습니다.

permission-aware RAG cases: 3
permission_leakage_count: 0
citation grounding fixtures: 6
agentic workflow fixtures: 2
first actual agentic target: note.update

원본 report는 OpenCairn repository의 baseline PR에 결과 artifact로 남겼습니다. 해당 PR이 merge되면 같은 파일은 main branch의 benchmark 결과 경로에서도 볼 수 있습니다.

RAG and Agent first baseline PR

RAG는 정답보다 권한을 먼저 봐야 합니다

처음에는 retrieval 품질을 생각하면 top-k, embedding, rerank 같은 것들이 먼저 떠올랐습니다. 실제로 중요합니다. 질문에 맞는 문서를 못 찾으면 답변도 좋아질 수 없습니다.

그런데 제품으로 보면 더 먼저 봐야 하는 것이 있었습니다. 사용자가 볼 수 없는 자료가 검색 결과나 citation에 섞이면 안 된다는 점입니다.

예를 들어 팀 workspace 안에 개인 프로젝트와 공유 프로젝트가 같이 있고, 질문의 정답은 개인 프로젝트 안에만 있다고 해보겠습니다. 검색 모델 입장에서는 그 문서가 가장 관련 있을 수 있습니다. 하지만 사용자가 그 프로젝트를 읽을 수 없다면 OpenCairn은 그 문서를 근거로 쓰면 안 됩니다.

그래서 첫 번째 지표는 성능 점수가 아니라 permission_leakage_count = 0이어야 한다고 봅니다.

질문
-> candidate retrieval
-> permission filter
-> citation build
-> answer generation

이 전체 경로에서 권한 없는 자료가 한 번이라도 섞이면, 그 답변은 "아쉽다"가 아니라 실패입니다.

Citation도 진짜 근거인지 봐야 합니다

두 번째는 citation입니다. 많은 AI 제품이 출처를 보여주지만, 출처가 보인다고 답변이 근거 있는 것은 아닙니다.

답변 문장과 citation이 실제로 연결되어야 합니다. 어떤 citation은 같은 주제를 다루지만 그 문장을 직접 지지하지 못할 수 있고, 어떤 답변은 citation 없이 모델이 끼워 넣은 말일 수 있습니다.

제가 보고 싶은 지표는 이런 것들입니다.

citation_precision
- 인용된 근거가 답변 문장을 실제로 지지하는가

unsupported_claim_rate
- 근거 없는 주장이 얼마나 들어갔는가

answer_abstention_accuracy
- 근거가 부족할 때 모른다고 말하는가

특히 unsupported_claim_rate는 낮을수록 좋습니다. RAG 제품이 사용자 지식 위에서 답하는 척하면서 사실은 모델 기억이나 추측을 섞는다면, 그건 제가 만들고 싶은 방향과 다릅니다.

변하는 노트는 별도로 봐야 합니다

PDF나 업로드 문서는 상대적으로 단순합니다. 업로드 시점에 분석하고, 텍스트를 뽑고, chunk를 만들고, embedding을 저장하면 됩니다. 물론 parser 품질은 어렵지만, 적어도 원본이 계속 바뀌지는 않습니다.

노트는 다릅니다.

OpenCairn에서 노트는 사용자가 계속 고치고, 협업자가 동시에 편집할 수 있고, AI가 제안한 수정이 들어갈 수도 있습니다. 그러면 검색 인덱스는 노트의 현재 상태를 따라가야 합니다.

제가 측정하고 싶은 것은 fresh_note_hit_rate입니다.

노트 생성
-> 질문해서 검색 확인
-> Yjs 기반 본문 수정
-> 다시 질문
-> 최신 내용이 검색되는지 확인

이게 안 되면 노트 기반 지식 OS라고 말하기 어렵습니다. 오래된 embedding으로 그럴듯한 답을 만드는 제품이 되어버립니다.

Parser는 대충 텍스트만 뽑으면 부족합니다

OpenCairn은 PDF, Office, Markdown, Notion export, Google Drive file 같은 자료를 다뤄야 합니다. 여기서 parser는 조용하지만 아주 중요한 층입니다.

단순히 텍스트가 조금 나왔다고 성공으로 보면 안 됩니다. 제목 순서가 바뀌거나, 표가 망가지거나, 한국어가 깨지거나, 페이지 구조가 사라지면 나중에 RAG 품질도 같이 무너집니다.

그래서 parser 쪽은 이런 지표를 봐야 한다고 생각합니다.

text_recall
heading_order_accuracy
table_cell_f1
korean_text_integrity
canonical_document_validity

처음부터 거대한 benchmark를 만들 필요는 없다고 봅니다. 작은 PDF, 표가 있는 PDF, 한국어 문서, Markdown fixture 정도부터 시작해도 충분히 많은 약점이 드러날 것입니다.

에이전트는 계획보다 실행 기록이 중요합니다

에이전트 품질도 마찬가지입니다. "계획을 잘 세웠다"만 보면 부족합니다.

좋은 에이전트라면 목표를 실행 가능한 step으로 나누고, 위험한 작업은 승인으로 낮추고, 실제 실행 결과를 남기고, 실패했을 때 복구 방향을 보여줘야 합니다.

제가 보고 싶은 지표는 이런 것들입니다.

plan_validity_rate
unsafe_step_downgrade_rate
action_audit_completeness
approval_boundary_pass_rate
recovery_success_rate

특히 approval_boundary_pass_rate는 중요합니다. 삭제, 외부 export, 비싼 작업, 코드 실행 같은 것은 모델이 바로 실행하면 안 됩니다. 사용자가 승인하거나, 최소한 제품이 위험도를 명확히 보여줘야 합니다.

좋은 숫자는 실패를 숨기지 않아야 합니다

저는 OpenCairn에 "RAG score 92점" 같은 숫자를 바로 붙이고 싶지는 않습니다. 그런 숫자는 보기에는 좋지만, 실제로 무엇이 좋은지 알기 어렵습니다.

차라리 처음에는 작고 불편한 표가 낫습니다.

permission_leakage_count: 0
citation_precision: baseline
unsupported_claim_rate: baseline
fresh_note_hit_rate: baseline
table_cell_f1: baseline
approval_boundary_pass_rate: baseline

그리고 실패 예시를 같이 공개해야 한다고 봅니다. 어떤 질문에서 citation이 약했는지, 어떤 PDF 표가 망가졌는지, 어떤 agent plan이 너무 위험했는지 보여줘야 다음 개선이 가능합니다.

지금의 결론

OpenCairn은 좋은 RAG와 좋은 에이전트를 만들고 싶습니다. 하지만 지금 바로 "좋다"고 말하기보다, 무엇을 못하면 안 되는지부터 정하는 게 먼저라고 생각합니다.

제가 보는 핵심은 세 가지입니다.

RAG는 권한 없는 근거를 쓰면 안 됩니다.
Parser는 나중에 근거로 쓸 구조를 보존해야 합니다.
Agent는 직접 실행보다 검토 가능한 workflow를 남겨야 합니다.

이 기준을 먼저 세워야 랜딩페이지 문구도, GitHub README도, 기술 블로그도 덜 과장되게 쓸 수 있습니다. OpenCairn이 진짜로 좋아지는지는 결국 이런 fixture와 숫자 위에서 봐야 합니다.