susinlee 님의 블로그

첫 번째 작업: 결정하기 !항목선택프론트엔드Next.js (App Router, TypeScript, pnpm, standalone 출력)백엔드FastAPI + SQLAlchemy 2.0 + Alembic, uvDBPostgreSQL (compose 컨테이너, 볼륨). 임베딩 검색 시 pgvector 확장블로그 콘텐츠DB가 원천 소스. 관리자(나)가 로그인 후 웹 에디터에서 작성·수정·발행. 본문은 markdown 텍스트로 DB에 저장, 메타데이터·통계도 DB자동화 워커Python, uv, Anthropic SDK. 호스트 cron이 `docker compose run --rm worker` 실행LLM 호출추상 인터페이스 하나 + 어댑터 둘. 서버 기본은 Anthropic API(`claude-son..

이번 A0 결과는 중요 전환점임. 검색과 생성 각각의 성능을 평가할 때는 보이지 않았던 Agent 실행 제어 문제가 실제 제품 경로에서 드러남. 다행히 큰 실패 원인은 모델 성능 자체가 아니라 실행 구조에 있음. 그래서 A0 baseline 완료, Agent 단계는 조건부 통과임. UI·UX와 배포로 넘어가기 전에 반드시 수정할 항목이 있지만, 그 범위는 제한적임. 1. A0 결과 종합 이 결과에서 눈여겨볼 점은 Tool Selection은 상당히 잘 작동하는 반면, 최종 답변까지 도달하는 실행 경로가 불안정하다는 것. 실패 원인을 분해하면 다음과 같음.Primary failure건수판단budget_exhaustion6즉시 수정unsupported_claim5사례별 재검토tool_selection_fai..

여기서부터는 Grouned Generation / Answer Evaluation 단계. 검색 단계에서는 `query → relevant retrieval unit`을 평가했다면, 이제는 `query → retrieved evidence → answer claims → citations → final answer` 전체를 본다. 진행 순서.H10 retrieval configuration을 freeze앞으로 생성 실험 중 검색 설정을 동시에 만지지 않는다. 그래야 answer 품질 변화가 generation 때문인지 rerieval 때문인지 분리할 수 있다.Answer Contract부터 고정한다GonsiMate의 답변은 단순히 자연스러운 한국어가 아니라 최소한 다음을 만족해야 한다.질문에 직접 답할 것..

결론부터, 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 쪽은 상..