Honeywell HC900을 Modbus TCP로 직접 폴링 → gRPC → C# 크롤러 → PostgreSQL. 기존 Experion OPC UA 데이터 경로를 HC900 직접 통신으로 대체. - industrial-comm/cpp: C++ Modbus 게이트웨이 (gRPC 서버) - src: C# .NET 8 ASP.NET Core 크롤러 + 웹 UI (3-Layer) - mcp-server: Python FastMCP (RAG/NL2SQL/P&ID) - 다중 컨트롤러(N-Controller) 지원 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
7.7 KiB
7.7 KiB
The model Qwen3-8B does not exist.
6-1차 플랜트 원료 투입 경로 설명해줘
⚙ iiot-rag_trace_connections [start_tag=6-1, direction=downstream, max_depth=20]
태그 형식이 올바르지 않습니다. 예를 들어, "ficq-6113.pv" 또는 "p-6102"와 같은 형식을 사용해 주세요. 정확한 태그명을 알려주시면 도와드리겠습니다. ---> 얘 이거 정상이야?
- Thought: 3.3s 네, 정상입니다. trace_connections는 P&ID 장비 태그(예: t-6201, p-6102, xv-6115)를 입력받는데, 6-1은 area/sub_area 식별자라서 태그 형식 검증에서 걸린 겁니다. 6-1차(아마 P6-1)의 원료 투입 경로를 보려면 해당 설비의 구체적인 태그명(예: 원료 입구 밸브/펌프)을 find_tags로 먼저 찾아보시는 게 좋습니다. ⚙ iiot-rag_find_tags [query=원료, sub_area=P6-1] ⚙ iiot-rag_find_tags [query=feed, sub_area=P6-1]
- Thought: 370ms p-6101 (6-1 Raw Material Feed Pump to C-6111)이 보이네요. 이걸로 추적해보겠습니다. ⚙ iiot-rag_trace_connections [start_tag=p-6101, direction=downstream, max_depth=20]
- Thought: 999ms 경로가 비어있네요. P&ID 연결 데이터가 아직 구축되지 않은 것으로 보입니다. P6 관련 도면을 먼저 확인해볼까요? ⚙ iiot-rag_list_drawings [unit_no=P6]
- Thought: 812ms ⚙ iiot-rag_parse_pid_drawing [filepath=p6] ⚙ iiot-rag_run_sql [sql=SELECT tag_no, from_tag, to_tag, role, equipment_name FROM pid_equipment WHERE tag_no ILIKE 'p-61%' ORDER BY tag_no LIMIT 20]
- Thought: 919ms P&ID 연결 데이터가 부분적입니다. p-6101은 pid_equipment 테이블에 아직 등록되지 않았고, p-6102만 연결되어 있네요. 원료 투입 경로는 다음과 같이 추정됩니다: P-6101 (Raw Material Feed Pump to C-6111) — pid_equipment에 미등록 P-6102 → F-6101A, F-6101B (원료 투입 펌프 2, IBC) P-6114 (D-6113 → FT-6113, C-6111 리플럭스 순환) P-6116 (C-6111 하부 순환) P-6118 (E-6117 → FT-6118, 제품 이송) P&ID 도면 데이터가 아직 pid_equipment에 완전히 구축되지 않은 상태입니다. DXF 도면 파일을 파싱해서 연결 관계를 먼저 구축해야 정확한 경로 추적이 가능합니다. 필요하시면 도면 파싱을 진행할까요? ▣ Build · Big Pickle · 21.5s 아니, 니가 찾으라는게 아니라, Qwen3 8B FP8 이 이렇게 대답했다고
- Thought: 4.7s 아, 네. 그건 Qwen3 8B FP8이 잘못 판단한 겁니다. trace_connections는 설비 태그(예: p-6101, t-6201)를 입력받는 도구인데, LLM이 6-1이라는 area 식별자를 그대로 태그라고 착각해서 호출한 거예요. 올바른 동작은: 먼저 find_tags(query="원료", sub_area="P6-1")로 실제 태그명을 찾고 그 결과(p-6101)를 가지고 trace_connections(start_tag="p-6101")을 호출해야 합니다 Qwen3 8B FP8은 파라미터 수가 적어서 이런 도메인 추론(태그 명명 규칙 추측)에 취약합니다. 더 큰 모델이나 도구 선택 로직을 강화하는 system message가 필요해 보입니다. ▣ Build · Big Pickle · 8.6s 제품 추출 경로는? 제품 추출 경로를 파악하려면 정확한 태그명이 필요합니다. 예를 들어, "ficq-6113.pv" 또는 "p-6102"와 같은 형식의 태그명을 제공해 주시면, 해당 태그부터 시작하여 투입 경로를 추적해 드릴 수 있습니다. 정확한 태그명을 알려주시면 도와드리겠습니다. ▣ Plan · Qwen3 8B FP8 (probe) · 4.7s p-203 ⚙ iiot-rag_trace_connections [start_tag=p-203, direction=downstream, max_depth=20] 제품 추출 경로는 다음과 같습니다:
- P-203 (원료 투입 펌프) → T-203 (원료 저장 탱크 1)
- T-203 → P-6201 (원료 투입 펌프 1) → F-6101A, F-6201A (원료 필터 A)
- F-6101A, F-6201A → FT-6101, FT-6201 (원료 유량 측정) → FCV-6101, FCV-6201 (원료 유량 제어 밸브)
- FCV-6101, FCV-6201 → E-6103, E-6203 (원료 예열) → E-6211 (원료 저장)
- E-6211 → E-6212 (C-6211/기상물 액화) → D-6213 (리플럭스 버퍼 <20>럼)
- D-6213 → P-6214 (제품 이송) → FT-6213, FT-6218 (제품 유량 측정)
- FT-6213, FT-6218 → FCV-6213, FCV-6218 (제품 유량 제어 밸브)
- FCV-6213, FCV-6218 → XV-6223, XV-6224, XV-6221, XV-6222, XV-6225A, XV-6226A, IBC (제품 저장 경로 선택)
- XV-6221, XV-6222, XV-6223, XV-6224, XV-6225A, XV-6226A → T-6221, T-6222, T-6223, T-6224, T-6225, T-6226 (제품 저장 탱크) 이 경로에서 T-6221, T-6222, T-6223, T-6224, T-6225, T-6226은 제품을 저장하는 탱크이며, IBC는 임시 저장 장치입니다. 필요하신다면, 특정 부분의 상세한 설명이나 추가 정보를 제공해 드릴 수 있습니다. seed를 주니까 똑바로 대답하긴 하는데
- Thought: 3.2s 재미있는 케이스네요. 실제 DB 데이터와 비교해볼게요. ⚙ iiot-rag_run_sql [sql=SELECT tag_no, from_tag, to_tag, role, category FROM pid_equipment WHERE tag_no ILIKE 'p-203%' OR tag_no ILIKE 't-203%' OR tag_no ILIKE 'p-62%' OR tag_no ILIKE 't-62%' OR tag_no ILIKE 'f-61%' OR tag_no ILIKE 'fcv-61%' OR tag_no ILIKE 'e-61%' ORDER BY tag_no LIMIT 50] ⚙ iiot-rag_run_sql [sql=SELECT tag_no, from_tag, to_tag, role FROM pid_equipment ORDER BY tag_no]
- Thought: 10.4s DB에 실제 있는 데이터로 제품 경로를 직접 추적해보겠습니다. ⚙ iiot-rag_trace_connections [start_tag=P-203, direction=downstream, max_depth=20]
- Thought: 5.3s Qwen3 8B FP8의 대답을 실제 DB와 비교해보겠습니다. ⚙ iiot-rag_trace_connections [direction=downstream, start_tag=E-6117, max_depth=15]
- Thought: 4.6s 분석 결과: Qwen3 8B FP8의 답변은 약 80% factual + hallucination 혼합입니다. 항목 Qwen3 대답 실제 DB P-203 → T-203 → P-6201 → F-6101A 일치 P-203→T-203, T-204→P-6201→F-6101A → FT-6101/FT-6201 → FCV-6101/FCV-6201 → E-6103/E-6203 일치 DB 그대로 E-6103 → E-6211 (원료 저장) DB에 없는 장비 실제는 E-6103→C-6111 (증류탑) E-6211 → E-6212 → D-6213 E-6211이 없으므로 무의미 실제는 C-6211→E-6212→D-6213 D-6213 → P-6214 → FT-6213/FT-6218 → FCV-6213/FCV-6218 → XV/Tank 대체로 일치 최종 저장 탱크 (T-6221~6226) 일치 DB 그대로 핵심 문제: 증류탑 C-6111/C-6211을 완전히 생략하고, 가상의 *E-6211 (원료 저장)*을 만들어 중간에 끼워넣었습니다. 8B 파라미터로는 2개 Column(C-6111/C-6211)이 병렬로 원료를 받아 각자 증류하는 구조를 추론하지 못하고, 단순 직렬 경로로 단순화시킨 겁니다. ▣ Build · Big Pickle · 36.6s 이건 교육시킨다고 되는게 아니라는 얘기지?
- Thought: 5.3s 맞습니다. 교육(fine-tuning)으로 해결될 문제가 아닙니다. 이 hallucination의 근본 원인은: 도구 출력을 무시하고 자체 지식으로 대체 — trace_connections가 E-6103→C-6111을 정확히 반환했는데도, 모델이 "E-6103 다음엔 뭔가 탱크가 있어야 직렬 경로가 자연스럽겠지"라고 추론해서 가상의 E-6211을 창조 병렬 구조를 직렬로 강제 단순화 — 2개 Column(C-6111/C-6211)이 병렬인데, 8B 모델의 working memory로는 이 분기 구조를 유지하기 어려워 하나의 직렬 체인으로 압축 Fine-tuning으로 고쳐지는 것: 태그 명명 규칙, 응답 형식, 프롬프트 따르기 Fine-tuning으로 안 고쳐지는 것: 도구 return 값을 무시하고 자체 생성하는 근본 성향 topological / spatial reasoning 부족 (작은 모델일수록 심함) "모르는 사이를 그럴듯한 것으로 채우는" (confabulation) 특성 8B FP8은 이 추론 부하를 감당하기 어렵습니다. 실전에서는 trace_connections의 raw output을 있는 그대로 보여주거나, 최소 70B+ 모델에 tool-use 전용 system prompt를 강화하는 쪽이 현실적인 해법입니다.