HC900-Crawler/docs/diagnosis-status-report-fragmentation.md

진단: 현황 보고 시 LLM의 정보 분산 문제

작성일 2026-06-10 · 대상: LLM 채팅이 "장비 현황/공정 경로"를 보고할 때 종합해야 하는 정보 구조 결론 한 줄: 알람·이벤트 보고는 현 구조로 충분하다. 그러나 "장비 경로 + 실시간 값" 보고는 정보가 과도하게 분산되어 있고, 이미 실제 결함(FT/FCV 값 누락)을 일으켰다. 해결 필요.

---

1. 문제 제기

사용자가 "6-1차 원료 투입 경로 현황"을 물으면, LLM은 하나의 답을 만들기 위해 서로 다른 4곳의 정보를 직접 종합해야 한다:

#	정보	출처	형태
1	장비 연결(from/to, category, tag_dcs)	pid_equipment	1,173행, 다중행/태그
2	실시간 값(PV/SP/OP, 운전상태)	realtime_table / v_tag_summary	2,151행, enum 문자열
3	메타(desc, 단위, euhi/eulo, sub_area, 상태라벨)	tag_metadata (EAV)	7,401행, 14속성 long-form
4	필드계기 값 매핑 규칙(FT→제어기.PV, FCV→제어기.OP)	어디에도 테이블/도구 없음 — 산문(plant_context.md)에만 존재	규칙

실제로 직전 진단 한 번에서 LLM은 run_sql을 4회 이상 호출했고, 그 결과를 사람이 머릿속에서 join 했다. 그리고 #4 규칙을 적용하지 못해 FT-6101·FCV-6101 현재값을 -로 비우는 결함이 발생했다(사용자가 직접 지적).

---

2. 실측 근거 — 무엇이 분산되어 있나

G1. 장비 중심의 통합 뷰가 없다

• v_tag_summary는 base_tag(realtime 태그 보유분) 중심 → 384개만 노출. realtime 태그가 없는 장비·필드계기(FT-6101, 용기 D/T류, VP 등)는 아예 행이 없다.
• pid_equipment는 1,173개 장비를 담지만 값이 없다(연결·메타만).
• 두 테이블을 잇는 뷰/도구가 없어, "장비 → 연결 + 값 + 설명"을 한 번에 못 가져온다.

G2. 필드계기 값 해석이 산문에만 있다 (가장 치명적)

• FT/TT/LT/PT(측정) = 루프 제어기 .PV, FCV/TCV/LCV/PCV(개도) = 루프 제어기 .OP.
• 실증: realtime_table에 FT-6101%·FCV-6101% 0행. 값은 FICQ-6101.PV/.OP 안에만 있다.
• 이 매핑을 계산해 주는 뷰도 도구도 없다. trace_connections조차 노드마다 {tag}.PV만 문자 그대로 조회 → 필드계기는 live_state=None이 되고, OP는 아예 안 붙인다.
• 결국 LLM이 매번 손으로 추론해야 하고, 한 번이라도 빠뜨리면 곧바로 결함.

G3. tag_metadata가 EAV라 pivot 부담

• 14속성(area/euhi/eulo/state0~7/units/desc/sub_area)이 long-form. 한 장비의 메타를 보려면 pivot 필요.
• v_tag_summary는 그중 desc/area/sub_area 3개만 노출 → units·euhi/eulo·상태라벨은 여전히 직접 조회.

G4. enum 파싱 부담

• 운전상태가 {5 | R-RUN | } 문자열. 일부 뷰/trace_connections만 파싱하고, 일반 run_sql 경로에선 LLM이 매번 정규식 추론.

G5. 루프 멤버십이 휴리스틱

• FT-6101↔FICQ-6101 연결을 "루프번호 6101 공유"로 추정. 저장된 FK가 아니라 추론이라, 번호 규칙이 깨지는 장비에서 취약.

G6. 다축 정합 판단

• "P-6201: sub_area=P6-2(메타) vs F-6101A/B로의 크로스타이 존재(배관) vs L-STOP(현재상태)" — 세 축을 모아 판단해야 함. 이건 LLM 판단이 맞는 영역이나, 입력이 흩어져 있으면 실수 확률↑.

---

3. 솔직한 평가 — 충분한가?

보고 유형	현 구조	판정
알람 / 이벤트 / 펌프 운전 교차검증	generate_status_report + v_plant_running_state_* 뷰가 잘 통합	✅ 충분
장비 경로 + 실시간 값 현황 (사용자가 실제로 하는 보고)	4+ 쿼리 + 3개 파생규칙을 LLM이 매번 수작업 종합	❌ 불충분 · 이미 결함 발생

→ "지금 구조로 충분한가?"의 답은 부분적으로만. 경로형 현황 보고에 대해서는 구조적으로 부족하며, 이론이 아니라 실제로 한 번 깨졌다(FT/FCV -).

근본 원인: 결정론적으로 SQL/도구가 했어야 할 일(값 해석·조인)을 비결정론적인 LLM 산문 규칙에 떠넘기고 있음. 규칙이 늘수록 누락 확률이 누적된다.

---

4. 해결방안 (우선순위)

★ S1 (권장 · 영향 大/노력 中): 장비 중심 "해석 완료" 뷰 + MCP 도구

• v_equipment_status 뷰: 장비 1건당 한 행으로 { tag_no, desc, category, tag_dcs, from_tag, to_tag, from_at, to_at, resolved_value, resolved_kind(PV/OP), unit, live_state } 를 반환. 핵심은 필드계기 값 해석을 SQL의 CASE로 내장:
  • 트랜스미터 → 같은 루프 제어기 .PV
  • 제어밸브 → 같은 루프 제어기 .OP
  • 제어기 자신 → .PV/.SP/.OP 직접
  • enum은 뷰에서 파싱해 사람이 읽는 상태로
• MCP 도구 equipment_status(tags[]) 또는 trace_connections가 이 뷰를 사용 → 1회 호출로 G1·G2·G4·G5 동시 해소, LLM 종합 부담 제거.
• 데이터는 이미 다 있다. JOIN + CASE + enum 파싱이라 결정론적·테스트 가능.

S2 (노력 小): trace_connections 확장

• 노드마다 .PV만이 아니라 SP/OP + 필드계기→제어기 매핑된 값을 붙이도록 보강. S1보다 좁지만 즉효.

S3 (보강): 루프 멤버십 저장

• instrument→controller 매핑 컬럼/테이블로 G5의 휴리스틱을 FK로 대체. S1/S2의 정확도를 끌어올림.

S4 (임시방편 · 이미 일부 적용): plant_context.md 산문 규칙

• 2026-06-10 필드계기 매핑 규칙을 plant_context.md에 추가함. 동작하지만 LLM 준수에 의존 → 이미 한 번 실패한 방식. 1차 방어가 아니라 백업으로만 둘 것.

---

5. 권고

S1을 구현한다. 4쿼리+3규칙의 LLM 수작업 종합을, 데이터가 이미 존재하는 1개의 결정론적 호출로 바꾼다. 값 해석을 SQL로 내려보내면(테스트 가능한 자리) FT/FCV 누락 같은 결함이 구조적으로 재발 불가능해진다. S4(산문)는 S1이 들어오기 전까지의 임시 안전망으로만 유지한다.

미적용 시 리스크: 경로형 보고를 할 때마다 LLM이 규칙 누락·조인 실수를 낼 확률이 남고, 그때마다 사람이 검수해야 한다(이번처럼).

---

6. 재평가 — 문서 우선(document-first) 접근 (2026-06-10 추가, 채택)

S1(DB 뷰 신설)을 재검토한 결과, 현 제약(P&ID 자동추출 거의 불가능, 기존 연결 데이터 빈약)에서는 KB 문서 우선이 더 우월하다고 판단. 근거는 docs/kb/P6-1_경비물_제거_공정.md 같은 잘 쓰인 유닛 문서가 분산 지점 대부분을 이미 해소한다는 것:

분산 지점	DB 방식(S1)	문서 방식
G2 필드계기 값 매핑	SQL CASE 별도 구현	✅ FT-6113 → FICQ-6113 → FCV-6113 표기가 매핑 그 자체
G5 루프 멤버십	FK 테이블 신설	✅ 문서에 명시(추론 불필요)
G1 토폴로지+의미	뷰로 일부만	✅ 흐름도+캐스케이드+설계의도까지
작성 비용	P&ID 추출(불가) + 1,173행 적재	✅ 사람이 마크다운 1장(검증·수정 가능)

그러나 "문서 하나로 전부"는 아니다. 문서가 대체하는 것과 못 하는 것:

• ✅ 대체: 연결관계 · 제어루프 의미 · 필드계기 매핑 → 토폴로지/구조 지식의 단일 진실원
• ❌ 불가: 실시간 값(PV/SP/OP는 realtime_table), 집계/구조화 질의, 알람·이벤트 이력(generate_status_report가 담당)

→ 최종 아키텍처는 2-소스 모델: KB 문서(토폴로지·매핑) + DB(실시간 값·알람·집계). 기존 4소스+3규칙 → 2소스로 축소, 가장 까다로운 부분이 사람이 읽는 문서로 내려감.

리스크

1. KB 미적재: kb_documents 현재 0행 — 인프라(Qdrant 벡터검색 + search_kb/rag_query + KbIngestWorker)는 완비됐으나 P6-1 문서조차 아직 미적재. 적재 플로우부터 태워야 검색됨.
2. 태그 대소문자 불일치: 문서는 TI-6111a(소문자), realtime은 대문자 → 값 조회 시 정규화 필요.
3. RAG 검색 신뢰성: "현황 질의 → 유닛 KB 문서 검색 → 문서의 제어기 태그 실시간 값 조회" 절차를 plant_context.md에 명시해야 LLM이 일관되게 동작.
4. 커버리지: 유닛마다 좋은 문서 1장 필요(진짜 노동). 단, 불가능한 P&ID 추출 대신 검증 가능한 영속 지식을 만드는 노동이라 방향 타당.

채택 결정 및 실행

• 문서 우선 전환. pid_equipment는 삭제 않고(복원한 187 locked는 보조 백스톱) 주 진실원에서 보조로 강등.
• 실행: ① 기존 P6-1 문서 적재 + 동일 템플릿으로 유닛별 문서 작성, ② plant_context.md에 "유닛 KB 검색 → 실시간 값 조회 → 루프 표기로 필드계기 해석" 절차 명시, ③ DB는 알람/이벤트/집계 담당 유지.
• S1(뷰 신설)은 향후 P&ID 데이터가 풍부해질 때까지 보류. S4(plant_context 산문 규칙)는 문서 적재 전까지의 임시 안전망.

---

부록 · 현 자산 인벤토리

• 뷰: v_tag_summary(PV/SP/OP/INSTATE+desc/area/sub_area, base_tag 중심), v_analog_points, v_instrument_range, v_pump_signal_map, v_plant_running_state / _agg / _corroborated
• MCP 도구: trace_connections(토폴로지+PV enum), generate_status_report(알람·이벤트·펌프 교차검증), run_sql, query_pv_history, query_with_nl
• 프롬프트: prompts/plant_context.md(계기약어·enum 판정·경로설명·필드계기 매핑 규칙)
• 연결 데이터: pid_equipment 1,173행(연결 267, locked 187) — 2026-06-10 public→hc900 복원분