연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T02. Recursive Language Model과 긴 문맥 처리
이 주제만 보기- T02-1구조대응2025년 이후
Recursive Language Models
한국어 검토 보기
해결 문제
- 모델이 한 번에 읽을 수 있는 글자 수(문맥창)보다 훨씬 긴 입력을 어떻게 처리할 것인가.
- 문맥이 길어질수록 답 품질이 떨어지는 현상(문맥 부패)을 어떻게 피할 것인가.
핵심 구조
- 긴 입력을 대화창에 밀어넣지 않는다. 파이썬 실행 환경(REPL) 안의 변수로 올려둔다.
- 모델이 코드를 써서 입력을 훑고, 쪼개고, 필요한 조각에만 자기 자신을 다시 부른다.
- 이 재귀 호출이 끝나면 결과를 모아 최종 답을 만든다.
주요 결과
- 문맥창의 100배 규모 입력까지 처리했다고 보고한다.
- GPT-5 기준으로, 평가한 벤치마크들의 중앙값(가운데 값) 기준 압축 방식 대비 26%, 하위 호출을 쓰는 CodeAct 대비 130%, Claude Code 대비 13% 향상. 비용은 비슷한 수준. 평균이 아니라 중앙값이다.
- 후속 학습한 RLM-Qwen3-8B가 원본 Qwen3-8B보다 중앙값 기준 28% 좋았다. 본문에서는 네 개 평가 과제 중앙값 28.3%로 적는다.
- 위 수치는 모두 v3에서 들어온 것이다. v1(2025-12-31)에는 26%, 130%, 13%, RLM-Qwen3-8B가 없다. 그래서 인용 버전을 v3로 못 박았다.
한계
- 학회 심사를 거치지 않은 프리프린트다. abs 페이지에 게재 표시가 없고 comment는 "9 pages, 43 with Appendix"뿐이다.
- 코드 실행 환경(샌드박스)이 필요하다. 실행 비용과 지연이 붙는다.
- 재귀 호출 횟수가 늘면 비용이 예측하기 어려워진다.
우리 기능과의 연결
- AI 보고서 기능과 업무 실행 에이전트가 다루는 대용량 설비 로그, 장기간 생산 이력을 통째로 읽는 대신 코드로 훑고 부분 질의하는 구조로 대응할 수 있다.
T07. 구조화 출력, 스키마 검증, 문서 이해
이 주제만 보기- T07-10구조대응2025년 이후
XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models
XGrammar
한국어 검토 보기
해결 문제
- 문법 제약 생성이 실제 서비스에서 병목이 된다.
핵심 구조
- 어휘를 두 종류로 나눈다. 앞뒤 문맥과 무관해 미리 검사해 둘 수 있는 토큰과, 생성 시점에 해석해야 하는 토큰이다. 앞의 것을 미리 처리해 두고 뒤의 것만 실행 시간에 본다. 문법을 미리 펼쳐 두고 스택 구조를 효율화한다.
주요 결과
- 기존 방식 대비 최대 100배 속도 향상을 보고했다. 서비스 전체 관점에서 구조화 생성 부담이 거의 없는 수준이라고 주장한다.
한계
- 논문 수치는 특정 문법과 실행 환경 기준이다. 스키마가 매우 크거나 자주 바뀌면 준비 비용이 다시 늘어난다.
- 왜 우리와 관련 있나. AI 보고서와 에이전트가 대량 호출될 때 스키마 강제 비용을 줄이는 실행 엔진 후보다.
T08. OCR, VLM과 산업 현장 표시장치 판독
이 주제만 보기- T08-2구조대응2025년 이후
DialBench: Towards Accurate Reading Recognition of Pointer Meter using Large Foundation Models
DialBench와 MRLM (바늘형 계기 판독)
한국어 검토 보기
해결 문제
- 전력 설비의 바늘형 계기는 반사, 가림, 비스듬한 각도 때문에 자동 판독이 어렵다.
핵심 구조
- RPM-10K라는 계기 이미지 10,730장짜리 자료를 만들었다.
- MRLM이라는 시각언어모델을 제안한다. 바늘과 눈금 사이의 기하 관계와 인과 관계를 모델에 직접 넣는다.
- 교차 주의집중 결합과 적응형 전문가 선택으로 숫자 값을 만들어 낸다.
주요 결과
- 새 평가 묶음에서 제안 방식의 유효성을 보였다. 자료와 코드를 공개하겠다고 밝혔다.
한계
- 전력 설비 계기 중심이다. 프리프린트라 동료심사 검증은 아직이다.
우리 기능과의 연결
- 설비 데이터 수집에서 아날로그 계기 값을 자동으로 채우는 모듈의 구조로 대응해 볼 수 있다.
T12. 영상 이해와 근거 선택 (Vision-Language Model)
이 주제만 보기- T12-2구조대응2025년 이후
Adaptive Keyframe Sampling for Long Video Understanding
한국어 검토 보기
핵심 구조
- 키프레임 선택을 최적화 문제로 정의한다.
- 두 가지를 같이 본다. 하나는 프롬프트와의 관련도, 다른 하나는 영상 전체에 대한 커버리지(고르게 덮는 정도)다.
- 기존 MLLM 앞단에 끼워 넣는 모듈이다. 모델 본체는 건드리지 않는다.
주요 결과
- 긴 영상 벤치마크에서 고정 토큰 조건으로 영상 질의응답 성능이 올라갔다.
- 저자들은 "영상 기반 MLLM에서 정보 사전 선별이 중요하다"는 점을 강조한다. 코드를 공개했다.
한계
- 관련도와 커버리지의 균형점을 어떻게 잡을지가 하이퍼파라미터에 달렸다.
- 질문이 영상 전체에 흩어진 여러 사건을 요구하면 커버리지 항만으로는 부족할 수 있다.
푸는 문제
- 이미지 한 장이 아니라 긴 영상이 들어오면 시각 토큰이 모델 용량을 크게 넘는다.
- 정해진 토큰 예산 안에서 유용한 정보를 최대로 담아야 한다.
우리 기능과의 관계
- 설비 영상 장시간 녹화에서 이상 구간만 골라 AI 분석에 넘기는 사전 선별 단계에 대응한다.
- T12-1구조대응2025년 이후
Frame-Voyager: Learning to Query Frames for Video Large Language Models
한국어 검토 보기
핵심 구조
- 프레임 "조합"을 고르도록 학습한다. 프레임 하나씩이 아니라 T개 묶음 단위다.
- 학습 라벨 만드는 법이 핵심이다. M개 프레임에서 T개 조합을 여러 개 뽑아 기존 Video-LLM에 넣고, 예측 손실(loss)이 낮은 조합을 좋은 조합으로 순위 매긴다.
- 이 순위를 지도 신호로 써서 선택 모델을 따로 학습한다.
주요 결과
- 영상 질의응답 벤치마크 4종에서, 서로 다른 Video-LLM 2종에 끼워 넣어 모든 설정에서 개선을 보고했다.
- 끼워 넣기만 하면 되는 plug-and-play 방식이다.
한계
- 조합을 훑어서 라벨을 만드는 과정 자체가 비싸다. 조합 수가 늘면 비용이 급격히 는다.
- 라벨의 품질이 기준으로 쓴 Video-LLM 성능에 묶인다.
- 학습된 도메인 밖(공장 CCTV 같은 산업 영상)에서의 성능은 논문 범위 밖이다.
푸는 문제
- 영상 전체를 모델에 넣을 수 없다. 입력 토큰 상한 때문이다.
- 기존 방식인 균등 샘플링(일정 간격으로 뽑기)과 글-프레임 검색은 정보 밀도 차이와 복잡한 지시문을 반영하지 못한다.
우리 기능과의 관계
- 영상 안전 판단에서 "이 장면 중 어느 프레임을 근거로 볼지"를 질문에 맞춰 고르는 구조에 대응한다.
T14. 산업용 프로토콜 번역, 코드 생성, 프로그램 합성
이 주제만 보기- T14-5구조대응2025년 이후
Training LLMs for Generating IEC 61131-3 Structured Text with Online Feedback
한국어 검토 보기
해결 문제
- IEC 61131-3 정형 텍스트는 공개 학습 데이터가 적다. 문법도 까다롭다. 그래서 일반 모델이 잘 못 쓴다.
핵심 구조
- 선호 기반 학습을 온라인으로 돌린다. 컴파일러 피드백과 LLM 기반 전문가 평가를 매 회 반영해 미세조정한다.
주요 결과
- 컴파일 성공률이 올라갔다. 기존 모델보다 나은 성능을 보고한다.
한계
- 컴파일 성공이 곧 현장 안전성은 아니다. 평가자 역할을 다른 LLM이 맡아 편향 가능성이 있다.
우리 기능과의 연결
- 회사 연결: 실행 결과를 다시 학습 신호로 넣는 구조는 설비 데이터 수집 드라이버 코드나 변환 규칙을 스스로 고쳐가는 방식에 대응할 수 있다.
T15. OPC UA, Asset Administration Shell, MQTT과 제조 상호운용성
이 주제만 보기- T15-2.10구조대응2025년 이후
ESP32-Based Sparkplug B Gateway Framework for Brownfield PLC Integration into an IIoT Unified Namespace: A Data Foundation for Intelligent Industrial Systems
Šenk 외 (2026) 구형 PLC를 Sparkplug B 통합 이름공간에 붙이는 게이트웨이
한국어 검토 보기
해결 문제
- 이미 깔린 구형 PLC는 제조사마다 통신 규약이 다르다. 교체는 현실적으로 어렵다.
핵심 구조
- ESP32 기반 저가 엣지 게이트웨이를 만들었다. Festo CI, Mitsubishi SLMP, Siemens S7comm을 각각 어댑터로 받아 MQTT/Sparkplug B로 올린다. ISA-95 계층에 맞춘 통합 이름공간을 Ignition에 구성했다. 게이트웨이와 브로커 사이는 TLS로 보호한다.
주요 결과
- PLC와 구성별로 각각 2만 회씩 측정했다. TLS를 켠 상태에서 요청부터 발행까지 평균 시간은 Festo 38.62밀리초, Mitsubishi 20.28밀리초, Siemens 16.80밀리초였다.
한계
- PLC 3종에 한정된다. 게이트웨이 하드웨어가 저사양이라 고빈도 대용량 수집에는 제약이 있다.
T16. 제조 지식그래프와 시맨틱 레이어
이 주제만 보기- T16-6구조대응2025년 이후
Knowledge Graphs as the Missing Data Layer for LLM-Based Industrial Asset Operations
한국어 검토 보기
해결 문제
- 설비 보전 질문에 언어모델 에이전트가 답하게 하면 정확도가 낮다. 문서를 평평하게 쌓아둔 저장소 위에서는 추론이 흔들린다.
핵심 구조
- 먼저 타입이 정해진 지식그래프를 근거 층으로 깐다. 그 위에서 질문을 성격에 따라 세 갈래로 나눠 보낸다. 첫째, 언어모델이 Cypher 질의를 만들어 구조화 검색을 한다. 둘째, 그래프로 바로 풀리는 질문은 언어모델을 아예 안 거치고 그래프 연산과 최적화로 확정 계산한다. 셋째, 데이터에 아예 없는 답은 생성 증강 지식(GAK, 언어모델이 없는 사실을 만들어 채우는 방식)으로 채운다. 이때 만들어낸 사실은 출처 표시를 붙인 노드로 그래프에 다시 넣고 나서 답한다.
주요 결과
- 기본 정확도가 65%에서 82~83%로 올랐다. 그래프로 풀리는 문제만 보면 99%다. 그래프는 라벨 9종, 간선 5종, 노드 12,647개 규모다.
한계
- 벤치마크 시나리오가 IBM 벤치마크와 겹친다. 잔여수명 예측 같은 예측 과제는 그래프가 맥락만 줄 뿐, 실제 예측은 별도 모델이 있어야 한다.
우리 기능과의 연결
- AI 보고서와 업무 실행 에이전트가 근거 없이 답하지 않게, 지식그래프를 근거 층으로 까는 방식과 구조가 대응한다.
T17. 자연어를 SQL로 바꾸기와 근거 기반 보고서 생성
이 주제만 보기- T17-9구조대응2025년 이후
MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL
MAC-SQL
한국어 검토 보기
해결 문제
- 데이터베이스가 크고 질문이 여러 단계 추론을 요구하면 모델 하나로는 버겁다.
핵심 구조
- 역할이 다른 에이전트 셋이 나눠 푼다. 중심 에이전트가 질문을 작은 질문으로 쪼개 풀고, 보조 에이전트 하나가 필요한 표만 추려주고, 다른 하나가 틀린 SQL을 고쳐준다.
주요 결과
- GPT-4로 BIRD 실행 정확도 59.59%를 기록했다. 발표 시점 최고 성적이다.
- 이 방식으로 만든 학습 데이터로 오픈소스 모델 SQL-Llama를 미세조정했다. 실행 정확도 43.94%로, 기본 GPT-4의 46.35%에 근접했다.
한계
- 에이전트 사이 대화가 늘어 호출 비용과 지연이 커진다. 보조 에이전트가 표를 잘못 추리면 그 오류가 뒤로 그대로 넘어간다.
우리 기능과의 연결
- 역할을 나눈 에이전트가 협업해서 하나의 답을 만드는 구조는 우리 업무 실행 에이전트 설계와 기술적으로 대응할 수 있다. 작은 모델로 큰 모델 성능을 좇는 방식도 현장 서버 배포 조건과 맞물린다.
T18. AI 품질관리, 모델 모니터링, 감사기록
이 주제만 보기- T18-12구조대응2025년 이후
Provenance Tracking in Large-Scale Machine Learning Systems
한국어 검토 보기
검토 메모
- 푸는 문제. 대규모 학습 과정에서 무엇이 어떤 자원을 얼마나 썼고 어떤 결과를 냈는지 되짚을 방법이 필요하다.
- 핵심 구조. yProv4ML 라이브러리를 낸다. 출처 정보를 JSON으로 모으고 W3C PROV와 ProvML 규격을 따른다. 플러그인으로 확장하고 yProv 워크플로 관리 체계와 연결된다.
- 결과. 학습 실행의 자원 사용 패턴을 추적하고 비효율 지점을 찾아내며 재현성을 확보하는 사례를 보였다.
- 한계. 고성능 컴퓨팅 환경 중심이다. 워크숍 논문이라 대규모 비교 실험은 없다.
- 우리와의 관계. AI 기준정보 생성과 AI 보고서가 어떤 원천 데이터에서 나왔는지 되짚는 감사기록 구조와 기술적으로 대응할 수 있다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기