susinlee 님의 블로그

결론부터, H9를 더 파는 단계는 거의 끝났고, 다음 controlled experiment로 넘어가도 됨.다만, wighted RRF를 튜닝하는 것이 아니라 하나의 failure mechanism만 겨냥한 비대칭 fusion 가설로 가는 게 맞음. 이번 결과에서 중요한 건 "남은 3건이 같은 이유로 망가진 게 아니다"라는 점임. 지분증권은 intersection이 0인데도 `8 → 15`로 밀렸음. 원인은 Dense-only 1~7위가 BM25 8위보다 앞서는 symmetric rank competition임. 알테오젠 우선주는 반대로 Dense-only 영향이 0인데 `4 → 11`로 밀림. 원인은 intersection 8개가 강제로 앞서는 intersection dominance임. 특수 관계자는..

결론부터 말하면 다음 단계로 RRF Hybrid 실험을 진행해도 됨.Dev에서 Dense와 BM25의 failure complementarity를 실제로 관측했기 때문.BM25와 Dense-D2a는 상당 부분 같은 질문을 해결하지만, Dense 실패 12건 중 10건을 BM25가 복구하는 비대칭적인 complementarity가 관측됨1. 전체 판단"Dense와 BM25가 서로 다른 failure mode를 가지는가?" 를 확인했고, 답은 Yes. Hit@10에서 both hit 32Dense only 1BM25 only 10both miss 2--------------------total 45 Dense가 실패한 질문은 ..

Retrieval Quality를 어떻게 시작할 것인가여기부터는 프로젝트의 중심축이 바뀜. 지금까지는 "시스템을 동작하게 만든다." 였다면 앞으로는 "검색이 왜 잘되고 왜 실패하는지를 측정하고, 개선을 실험으로 증명한다." 바로 BM25나 Hybrid를 구현하지 않고 현재 Dense-D2a가 정확히 얼마나 잘하고 있는지부터 숫자로 고정할 것.그렇지 않으면 나중에 전략이 바뀌어도 무엇이 좋아졌는지 증명할 수 없음. 이번 UI dogfooding에서 좋은 failure seed도 나옴. 예를 들면:"이수페타시스의 주요 사업은 무엇인가?"실제 retrieval:2026.06 반기보고서II. 사업의 내용 사업보고서가 더 적절하다고 생각할 수도 있지만, 최신 반기보고서가 동일한 내용을 정확히 제공한다면 이건 Wr..

작업 결과이번 작업에서 잘 된 부분이 꽤 많음. 첫째, UI가 새 프레임워크를 억지로 끌어오지 않고 기존 FastAPI + 정적 HTML/CSS/JS로 붙은 건 좋음. 지금 단계에서는 React/Next 같은 걸 넣어서 프론트 구조 자체가 새로운 프로젝트가 되는 것보다, 기존 `/ask` SSE를 그대로 소비하는 얇은 UI가 훨씬 적절함. 둘째, citation 연결 방식이 좋음. UI가 답변 텍스트를 보고 임의로 `[1]`을 추측하는 게 아니라 Backend의 `citation_id / evidence_id`를 기준으로 drawer를 여는 구조라서, citation이 단순 장식이 아니라 실제 evidence object에 연결됨. 셋째, 지원 기업과 `corpus_as_of`를 UI에 하드코딩하지 않고..

이전 작업 결과지금까지 따로 놀던 Agent decision, parser generalization, correction/versioning이 이제 제품 검색 경로 하나로 합쳐질 준비가 된 상태가 됨. ● LLM이 `answer_directly / search_disclosures / ask_clarification을 선택하게 한 점, 검색 실패를 structured observation으로 모델에 다시 넘긴 점, 회사별 꺾쇠 allowlist 대신 구조적 parser rule을 만든 점은 방향이 좋음. 반면 이제 가장 큰 미해결 문제는 파서가 아니라 "여러 기업·여러 filing version을 실제 제품 검색 경로에서 어떻게 선택하고 검색할 것인가" 가 됨. 1. 실제로 해결된 것Agent 쪽은 상..

이전 작업 결과 ― 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으로 빠지고, 지원되지 않는 기업도..