302183c97e
- P&ID: 연결 분석 API, Prefix 규칙 관리, 카테고리 분류, DXF 그래프 빌드 - LLM: 대화 요약, tool card 영구 보존, 시계열 차트(uPlot), 에이전트 모드 - KB: 청크 미리보기, Field Instrument Inference, 인증/Qdrant 클라이언트 - MCP: 서버 기능 확장, 파이프라인 수정, timeout 개선 - Frontend: P&ID UI, LLM UI, KB UI, OPC UA Write 탭 추가 - 설정: AGENTS.md, plant_context, README, opencode.json 업데이트 - 정리: 진단 체크리스트 문서 삭제
7.2 KiB
7.2 KiB
결정 보류 2건 — 사용자 액션 가이드
작성일: 2026-05-14 대상:
plans/빅피클-잔여작업-코딩계획.md7번(현장 재고), 8번(BGE-M3) 상태: 코드 작업 불필요. 사용자 의사 결정과 운영 액션이 필요.
1. 현장 재고 데이터 출처 결정
현황
Phase 0 설계서(G3)에서 "현장 재고 데이터 자체가 시스템에 없음"으로 식별됨. 운전원이 "P-6201 펌프 예비품 재고", "교체용 PT100 센서 수량" 같은 질문을 했을 때 참조할 데이터 소스가 없어 답변 불가.
결정해야 할 것
| 옵션 | 설명 | 사용자 액션 |
|---|---|---|
| A. KB 업로드 (권장) | 엑셀/CSV/PDF 재고 대장을 plant_operation 또는 report 컬렉션에 업로드 → 즉시 RAG 검색 가능 |
1) 재고 대장 파일 확보 (관리부/구매팀 협조) 2) 컬럼 구조 정리 (품목·규격·수량·위치·재발주점) 3) 14번 탭 "RAG 관리" → 업로드 |
| B. ERP/MES API 연동 | 외부 시스템에서 실시간 재고 조회 | 1) ERP 운영팀과 API 협의 2) 인증/네트워크 방화벽 정책 3) 별도 개발 필요 (Phase 8) |
| C. 수동 입력 테이블 | PostgreSQL에 inventory_table 신설, 관리자 UI에서 직접 입력 |
1) 누가 어떻게 최신화할지 거버넌스 결정 2) 별도 개발 필요 |
| D. 보류 유지 | 운전원 질문 시 "재고 정보는 별도 시스템 참조" 안내 | 운전원 교육 |
권장: 옵션 A
근거:
- 현재 KB 시스템(Qdrant 5종 컬렉션)이 이미 운영 중
- xlsx/pdf 자동 파싱 + 임베딩 + 한국어 검색 모두 동작
- 코드 추가 0줄, 즉시 시도 가능
- 부족하다면 그때 B 또는 C로 확장
사용자가 해야 할 일 (옵션 A 채택 시)
- 재고 대장 파일 확보
- 관리부/구매팀에서 최신 재고 엑셀 입수
- 민감정보(가격·공급사 단가 등) 제외 또는 가공 결정
- 업로드
- 앱 접속 → 14번 "RAG 관리" 탭
- 관리자 비밀번호 로그인
- 컬렉션 =
plant_operation(또는 신규inventory컬렉션을 원하면 DB 시드 확장 요청) - 태그 =
inventory,예비품등 일관된 태그 부착
- 검증
- 채팅(#13)에서 "PT100 센서 재고 알려줘" 같은 질문으로 검색 결과 확인
- 결과가 부정확하면 청크 미리보기(🔍 버튼)로 인덱싱 품질 확인
- 운영 룰
- 월 1회 or 분기 1회 최신 파일 재업로드 (이전 버전은 "🚫 비활성화" 후 "🗑 정리")
- 갱신 주체 1명 지정
사용자가 해야 할 일 (옵션 B/C로 갈 경우)
이 문서 범위 밖. 별도 요건 정의서가 필요. 본 항목은 옵션 결정만 요청.
2. 임베딩 모델 BGE-M3 마이그레이션 검토
현황
- 현재 사용 중:
nomic-embed-text(768-dim, Ollama 호스트) - 후보:
bge-m3(1024-dim, 다국어 SOTA, 특히 한국어 성능 우수) - 5개 Qdrant 컬렉션이 768-dim으로 생성된 상태
결정해야 할 것
전환 시 이득과 비용을 비교 후 GO/NO-GO/POSTPONE 결정.
| 이득 | 비용/위험 |
|---|---|
| 한국어 검색 품질 향상 (대시기관 평가 기준 +5~15%) | Qdrant 컬렉션 5개 전부 재생성 → 기존 인덱스 일시 소실 |
| 멀티링구얼(영문 매뉴얼+한국어 SOP 혼합)에 강함 | 1024-dim → Qdrant 디스크 사용량 +33% |
| Dense + Sparse + ColBERT 통합 모델 | 임베딩 속도 ~30% 느려짐 (GPU 점유율 ↑) |
| 청크 크기 8K 토큰까지 지원 (nomic은 2K) | Ollama가 bge-m3 미지원 시 다른 호스트 필요 (HF transformers 등) |
마이그레이션 절차 (실행 시)
- 사전 평가 ⚠️ (사용자 액션)
- BGE-M3가 Ollama Library에 있는지 확인 (
ollama pull bge-m3) - 없으면 대안 결정: HF transformers, sentence-transformers 또는 별도 임베딩 서버
- 현재 KB 검색 품질에 실질 문제가 있는지 — 운전원 피드백 수집 (1~2주)
- BGE-M3가 Ollama Library에 있는지 확인 (
- 샘플 비교 (선택) (사용자 액션)
- 동일 한국어 쿼리 10건을 두 모델로 비교
- 한국어 정밀도에서 명백한 개선이 보일 때만 GO
- 백업 (사용자 액션)
storage/kb/전체 백업pg_dump로kb_*테이블 백업
- 코드 작업 (개발자 액션 — 본 문서 범위 아님)
appsettings.json에Kb:EmbeddingModel,Kb:VectorSize설정 추가KbEmbeddingClient.cs에서 모델명/차원 환경변수 참조KbStartupService.cs에서 컬렉션 차원 mismatch 감지 시 재생성
- 컷오버 (사용자 액션)
- 운영 외 시간대 선택 (KB 검색 일시 중단)
- Qdrant 컬렉션 5개 삭제 → 새 차원으로 재생성
- 모든 KB 문서 일괄
재인덱싱(↻)트리거 - 완료까지 모니터링 (문서 수 × 청크 수 × 임베딩 시간)
권장: POSTPONE (당분간 보류)
근거:
- 현재 nomic-embed-text 검색 품질이 운영에 임계 미달이라는 정량 증거가 없음
- BGE-M3 전환은 비가역적 비용(재인덱싱 시간, 디스크 +33%)이 큰 결정
- Phase 7 신규 기능(채팅 통합·청크 미리보기·요약 등)이 운영에서 안정화된 후 사용자 피드백으로 검색 품질 이슈가 누적되면 그때 검토
사용자가 해야 할 일
- 1~2개월간 운영하면서 KB 검색 결과가 부정확했던 사례를 메모
- 질문 / 기대 답변 / 실제 검색된 문서 / 점수
- 메모 위치: 별도 텍스트 파일 또는 본 문서에 추가
- 사례가 5건 이상 누적되고 한국어 매칭 실패가 패턴화되면 마이그레이션 재검토 회의
- 회의 시점에 다시 본 문서를 갱신 (GO/NO-GO 결정 기록)
즉시 가능한 대안 (개발자 액션 불필요)
검색 품질이 부족할 때 BGE-M3 전환 없이 시도해 볼 수 있는 것:
| 시도 | 방법 |
|---|---|
| 더 좋은 청킹 | 업로드 시 chunking_policy 옵션 조정 (현재는 자동) |
| 태그 보강 | KB 업로드 시 태그를 풍부하게 부착 → search_kb의 tags 필터로 정확도 ↑ |
| 컬렉션 분리 | doc_type별 5개 컬렉션을 더 세분화 |
top_k 조정 |
채팅에서 검색 결과 수를 늘려 LLM이 더 많은 단서로 답하게 |
체크리스트 요약 (사용자가 해야 할 일)
단기 (이번 주 ~ 2주 내)
- 재고 데이터: 옵션 A(KB 업로드) 채택 여부 결정 → 채택 시 관리부에 파일 요청
- BGE-M3: 마이그레이션은 보류, 검색 품질 모니터링 시작
중기 (1~3개월)
- 재고 KB 파일 1차 업로드 + 검증
- KB 검색 부정확 사례 누적 (5건 임계)
장기 (3개월+)
- BGE-M3 마이그레이션 재검토 회의 (사례 누적 시)
- 재고 데이터를 ERP 연동으로 격상할지 검토 (옵션 A로 한계 도달 시)
본 문서 갱신 규칙
이 문서는 결정이 진행됨에 따라 사용자가 직접 갱신합니다.
- 결정 완료 시: 해당 섹션에 "결정 결과", "결정자", "결정일" 추가
- 보류 유지: "재검토 예정일" 추가
- 옵션 변경: 새 옵션 행 추가 + 이전 결정 사유 보존