susinlee 님의 블로그

retrieval 실험 코드를 실제 제품 경로로 처음 연결한 스프린트였음.다만, 아직 LLM Agent 제품의 완성형이 아니라, Agent 제품의 실행 골격 + deterministic fallback generator에 가까움. 보기좋게 정리하자면자연어 질문 → 기업 식별 → 검색 여부 판단 → Dense-D2a 검색 → Evidence 생성 → Citation 검증 → SSE 응답최종 답변 생성과 agent decision은 아직 진짜 LLM 기반이 아님. `POST /ask`가 SSE로 동작하고,사용자가 기업을 미리 선택하지 않아도 질문에서 기업명을 추출한 뒤 registry를 통해 `corp_code`를 확정함.모호한 기업은 검색하지 않고 clarification으로 빠지고, 지원되지 않는 기업도..

먼저 E186에 대해서 짚고넘어가자면... E186 관련 지표를 유지하는 것은 의미가 없지는 않음. 다만 그걸 "공시 오류 탐지 능력"의 지표로 해석하면 안 됨.E186은 사람이 원문을 감시하면서 잘못되었다는 사실을 알아낸 특수 사례임. 시스템은 "이 숫자는 공시 작성 오류다"라는 능력을 가지고 있지 않음. 지금 E186 지표가 답하는 질문은"평가셋에서 사람이 이미 conflicting evidence라고 판정한 문서가 있을 때,retriever/reranker/context builder가 그것을 정답 근거보다 앞세우는가?" 반면 답하지 못하는 질문은"새로운 공시에서 알려지지 않은 오류를 시스템이 발견할 수 있는가?" 다만 구분을 하나 도입하는 걸 추천.`known-conflict robustness..

결론부터D2a Dense는 여전히 가장 강한 단일 retriever.특히 @20에서 25/27 claim, 6/8 question으로 RRF의 23/27, 5/8보다 좋음. 반면 @3, @5에서 상당한 이득을 보여서 sparse/dense 상보성이 실제로 존재함.즉, "Hybrid가 실패했다"도 아니고 "Hybrid가 baseline을 대체했다"도 아님. Sparse와 Dense의 상보성은 확인됨 → 고정 1:1 RRF는 그 상보성을 완전히 보존하지 못함→ 현재 RRF 구현에도 tie 처리 문제가 하나 있음1. 요청했던 invariant 10개를 검토하면실험 invariant는 대부분 제대로 지켜졌음. Representation, query rewrite, reranker, parser, chunker..

1. D2b 문제는 제대로 바로 잡혔다D2b = row-atomic retrieval experiment 로만 참고하고,compact representation의 효과는 새 D2c로 판단할 수 있게 됐음.2. 이번 D2c는 우리가 원래 원했던 실험이 맞다이번에는 독립변수가 제대로 통제됨. D2a와 D2c 모두:Retrieval Units = 2,869RU ID 동일canonical mapping 동일source span 동일split topology 동일1:N canonical chunk = 5 바뀐 건 eligible table 745개의 embedding용 문자열뿐임. 이게 바로 우리가 원해던 실험.즉 이번 결과부터는 실제로 "compact table representation의 효과" 라고 해석해도..

이전 실험 결론D2a는 채택할 가치가 있고, D2b는 폐기한다. 다음에는 표 serialization을 더 만지지 말고, Q05-C3의 structural-context 문제를 딱 한 번 확인한 뒤Hybrid Retrieval로 넘어가는 게 좋다.1. 이번 작업에서 실제로 확정한 것먼저 아키텍처가 꽤 깔끔히 분리됨.Original Source→ Element→ Canonical Chunk→ Retrieval Unit→ Search Result→ Context Unit→ Generation 특히 중요한 변화는 이제 검색 모델에 들어가는 객체가 Canonical Chunk가 아니라 Retrieval Unit으로 명시됐다는 것.Gold evidence는 여전히 원본 source ref/span에 고정되고,Re..

결론부터12,711-token chunk는 packing bug가 아니라 "1x1 표 셀 하나가 문서 여러 소절을 통째로 담고 있어서" 생겼음따라서 parser보다는 chunking/retrieval-unit contract 문제에 가까움D1 structured serialization은 실패함. Dense 검색을 개선하지 못했고 오히려 잘 검색되던 E228을 악화시킴`Canonical Source → Rerieval Unit → Context Unit` 분리 방향은 맞지만, 현재 context budget 정책은 조금 수정해야 함headline 결과를 보면 분명한데, D0 Dense는 @5에서 `15/27 claim`, `2/8 question` 이었는데, D1은 `9/27, 1/8`로 떨어짐.@20에..

요약BM25 baseline을 잠근 뒤 BGE-M3 dense-only baseline까지 붙였고,Dense가 의미적 표현 차이에는 확실히 강했지만 표 표현 방식과 multi-evidence 결합에서는 아직 한계가 드러난 상태. 먼저 큰 그림부터현재 파이프라인은 아래와 같음고정 원본→ Parser→ Element / Cell lineage→ Gold evidence→ Structural Chunking→ BM25 baseline→ Q07 gold 재설계→ E186 conflict semantics 정리→ Dense Retrieval baseline(BGE-M3)→ [현재 위치] 다음 후보는 에이전트가 제안한 대로 structured table serialization인데, 결과를 보면 꽤 타당한 선택임...

중간 점검 1을 정리하며 궁금한 점들에 대한 답변.1·2 언제 "금융 공시 검색 Recall@5가 18%다"라고 할 수 있는가, 그리고 출시 후 에이전트 성능은 어떻게 평가하는가현재 `5/27 = 18.52%`는 정확한 계산이지만, 의미는 매우 작음.현재 인덱스는 이수페타시스FY2025 사업보고서 한 건2,803개 청크이고독립 양성 질문 8개에서필수 claim 27개를 평가함.따라서 현재 말할 수 있는 것은:"이수페타시스 FY2025 사업보고서 한 건에 대해 사람이 검수한 10문항 회귀셋에서, 독립 양성 문항의 필수 주장 27개를 기준으로 BM25 claim Recall@5는 5/27(18.52%)였다" 반대로"우리 금융 공시 검색기의 Recall@5는 18.5%다" 라고 일반화하려면 평가 데이터셋 자체..