susinlee 님의 블로그

이전 작업 결과 ― 4개 기업 확장"전체 파이프라인이 이수페타시스에 특화된 건 아니지만, parser의 허용 정책은 꽤 강하게 특화돼 있었다" 삼성전자·삼양식품·알테오젠·대상 4개 회사를 골라 총 19건의 공시를 받았는데,parser 결과는 success 3건, partial 16건, failure 0건이었음.실제 제품 색인까지 들어간 건 삼성전자 3건뿐이고,나머지 3개 회사는 다운로드와 element 추출까지는 됐지만 parser contract 때문에 검색 가능한 상태까지 못 갔음. 앞단의 parser admission rule이 다른 기업을 너무 많이 탈락시키고 있음. 구체적으로 보면 partial 16건의 주된 원인은 `uncertain_named_angle`임. ``, ``, ``, `` 같은 ..

이번 작업에서 의미 있는 변화 셋.첫째, 검색 후보 20개와 생성 컨텍스트가 분리됐음. Dense retrieval은 `top_k=20`으로 recall을 확보하고,Context Builder가 별도 relevance scoring 없이 dense 순서를 유지하면서token budget 안에 들어가는 Evidence만 생성 모델에 전달함. 둘째, 전체 생성 후 24자씩 잘라 보내던 가짜 SSE가 없어지고,`evidence_ids`가 현재 run에서 유효하다고 확인된 claim부터 실제 생성 중에 사용자에게 나가게 됐음. 셋째, 본문에 `"2025"` 같은 문자열이 있느냐로 판단하던 temporal guard 대신 DART filing metadata의 보고기간을 사용하게 됐고, 사건 시점과 filing ..

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에..