susinlee 님의 블로그

이번 학습을 끝마치면 다음 질문에 답할 수 있음."왜 도면을 벡터 DB에만 저장하지 않고 그래프 DB를 사용하지?""도면에 그려진 문과 실제 건축 객체는 어떻게 구별하지?""온톨로지는 어디에 필요하고 어떤 것을 정의하지?""에이전트가 답변의 근거를 어떻게 검증하지?"전체 학습 로드맵정보와 지식의 차이데이터, 정보, 지식, 의미, 맥락, 추론이 무엇인지 이해하기온톨로지의 기본 원리개체, 클래스, 인스턴스, 관계, 속성, 제약조건, 추론지식 그래프와 그래프 DB트리플, 노드, 엣지, RDF, Property Graph, Neo4j, SPARQL, Cypher건축 도면의 기초평면도, 입면도, 단면도, 상세도, 일람표, 축척, 기호, 도면 번호, 개정건축 데이터 표준BIM, IFC, bsDD, 객체의 형식과 인..

첫 번째 작업: 결정하기 !항목선택프론트엔드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에 하드코딩하지 않고..