연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T06. RAG, 지식그래프, 온톨로지, 출처 추적
- T06-1구조대응
Dense Passage Retrieval for Open-Domain Question Answering
한국어 검토 보기
해결 문제
- 질문에 맞는 문단을 찾을 때 오래도록 BM25 같은 단어 일치 검색을 썼다.
- 단어가 다르면 뜻이 같아도 못 찾는다.
주요 결과
- 상위 20개 문단 검색 정확도에서 Lucene BM25 대비 9%에서 19%포인트 앞섰다.
- 여러 오픈도메인 질의응답 벤치마크에서 당시 최고 성능을 세웠다.
한계
- 질문과 정답 문단 쌍이라는 학습 데이터가 필요하다.
- 문단 벡터 색인을 메모리에 올려야 해서 저장 비용이 든다.
- 대상이 위키피디아 문단이다. 설비 태그나 표 데이터는 다루지 않았다.
아키텍처
- 질문용 인코더와 문단용 인코더를 따로 두는 이중 인코더 구조다.
- 질문과 정답 문단 쌍만 있으면 벡터 표현을 학습할 수 있다.
- 학습한 벡터를 색인해 두고 가까운 벡터를 찾아 문단을 꺼낸다.
우리 회사와의 관계
- 매뉴얼과 작업표준 문서를 벡터로 색인해 뜻이 비슷한 문단을 찾아오는 검색 구조에 대응할 수 있다.
- T06-3구조대응
Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering
한국어 검토 보기
해결 문제
- 생성 모델만으로 답을 만들면 지식을 파라미터에 다 넣어야 해서 모델이 커진다.
- 검색한 문단을 여러 개 붙이면 좋은데, 한꺼번에 붙이면 계산량이 급하게 커진다.
주요 결과
- 큰 모델 기준 NaturalQuestions 정확일치 51.4점, TriviaQA 67.6점을 보고한다.
- 같은 표에서 RAG는 44.5점과 56.1점이다.
- 문단을 10개에서 100개로 늘리면 TriviaQA가 6%포인트, NaturalQuestions가 3.5%포인트 올랐다고 보고한다.
- 추출형 모델은 보통 문단 10개에서 20개 근처에서 성능이 멈춘다고 비교한다.
한계
- 학습 비용이 크다. 문단 100개로 학습하면 425 GPU 시간이 든다고 밝힌다.
- 답의 근거를 문장 단위로 표시하지는 않는다.
- 검색 대상이 위키피디아 문단이다. 표나 설비 태그는 다루지 않는다.
아키텍처
- Fusion-in-Decoder라고 부르는 구조다.
- 질문과 문단을 한 쌍씩 따로 인코더에 넣는다. 문단끼리는 서로 안 본다.
- 디코더에서 모든 문단의 표현을 한꺼번에 이어 붙여 답을 만든다.
- 인코더를 따로 돌리므로 계산 시간이 문단 수에 비례해서만 늘어난다. 제곱으로 늘지 않는다.
우리 회사와의 관계
- 매뉴얼, 작업표준, 이력 기록처럼 흩어진 문단을 여러 개 한꺼번에 읽어 하나의 답을 만드는 구조에 대응할 수 있다.
- T06-5구조대응
From Local to Global: A Graph RAG Approach to Query-Focused Summarization
한국어 검토 보기
해결 문제
- 보통 RAG는 "이 문서 어디에 답이 있나"는 잘 찾는다.
- 그러나 "이 데이터 전체의 주요 흐름이 뭐냐" 같은 전역 질문에는 약하다. 이건 검색 문제가 아니라 요약 문제다.
주요 결과
- 100만 토큰 규모 데이터에서 일반 RAG 대비 답의 포괄성과 다양성이 크게 올랐다고 보고한다.
한계
- 그래프와 요약을 미리 만드는 색인 비용이 크다.
- 평가가 LLM 심사 기반이라 정답이 딱 떨어지는 정량 지표는 아니다.
아키텍처
- 1단계에서 LLM으로 원문에서 개체 지식그래프를 뽑는다.
- 2단계에서 그래프를 커뮤니티(비슷한 개체 묶음)로 나누고, 묶음마다 요약을 미리 만들어 둔다.
- 질문이 오면 커뮤니티 요약들로 부분 답을 만들고, 그 부분 답을 다시 합쳐 최종 답을 만든다.
우리 회사와의 관계
- 설비 데이터와 기준정보를 개체 그래프로 묶어 "이번 달 전체 품질 이슈 흐름" 같은 AI 보고서를 뽑는 구조에 대응할 수 있다.
- T06-7구조대응
Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
한국어 검토 보기
해결 문제
- 무조건 검색해서 붙이면 필요 없는 문서까지 들어와 답 품질이 떨어진다.
- 검색된 문서가 답을 실제로 뒷받침하는지 스스로 검사하지 않는다.
주요 결과
- 7B, 13B 모델이 ChatGPT와 검색 붙인 Llama2-chat을 여러 과제에서 앞섰다고 보고한다.
- 긴 글 생성에서 사실성과 인용 정확도가 올랐다고 보고한다.
한계
- 반성 토큰을 학습시키려면 별도 학습 데이터와 미세조정이 필요하다.
- 자기 평가라서 모델이 틀린 확신을 가지면 걸러내지 못한다.
아키텍처
- 하나의 모델이 검색 여부를 스스로 판단한다. 여러 번 검색할 수도 있고 건너뛸 수도 있다.
- 반성 토큰이라는 특수 토큰을 생성 과정에 넣는다. 이 토큰으로 검색 필요성, 근거 뒷받침 여부, 유용성을 스스로 표시한다.
- 추론 단계에서 이 토큰 값으로 후보 답을 골라낸다.
우리 회사와의 관계
- AI 보고서와 업무 실행 에이전트가 근거 없이 단정하지 않도록 스스로 검사하는 구조에 대응할 수 있다.
- T06-8구조대응
Enabling Large Language Models to Generate Text with Citations
한국어 검토 보기
해결 문제
- LLM이 답은 잘 쓰는데 그 문장이 어느 문서에서 나왔는지 표시하지 않는다.
- 사람이 일일이 확인해야 해서 검증 비용이 크다.
주요 결과
- ELI5에서 가장 좋은 모델도 절반 정도는 인용 근거가 완전하지 않았다.
- 검색기 성능, 긴 문맥 처리, 여러 문서 종합이 개선 과제로 지목됐다.
한계
- 평가 중심 연구다. 인용을 잘 다는 방법 자체를 제시하지는 않는다.
- 대상이 영어 일반 문서다. 제조 문서나 수치 데이터는 다루지 않는다.
아키텍처
- ALCE라는 평가 벤치마크를 만들었다. 자동으로 인용 품질을 재는 첫 벤치마크라고 밝힌다.
- ASQA, QAMPARI, ELI5 세 데이터셋에 검색 코퍼스를 붙였다.
- 유창성, 정확성, 인용 품질 세 축으로 자동 지표를 만들고 사람 판단과의 상관을 확인했다.
우리 회사와의 관계
- AI 보고서가 문장마다 어느 설비 로그와 어느 기준정보에서 나왔는지 붙이는 기능의 평가 구조에 대응할 수 있다.
- T06-10구조대응
Provenance Semirings
한국어 검토 보기
해결 문제
- 데이터에 꼬리표를 붙여 다루는 방식이 분야마다 따로 있었다.
- 불완전 데이터베이스, 확률 데이터베이스, 중복 허용 집계, why-provenance가 각자 다른 계산법을 썼다.
- 서로 같은 얘기인지 아닌지 판단할 공통 언어가 없었다.
주요 결과
- how-provenance를 계산하는 일반 알고리즘을 준다.
- 같은 틀로 불완전 데이터베이스와 확률 데이터베이스의 질의 계산을 함께 처리한다.
- 일부 반환에서는 질의 포함 관계 판정이 기존 집합 의미론과 같다는 것을 보인다.
한계
- 관계형 질의와 datalog가 대상이다. 머신러닝 파이프라인이나 LLM 생성물은 다루지 않는다.
- 다항식 꼬리표를 그대로 두면 크기가 빠르게 커진다. 저장 비용은 실무 과제로 남는다.
아키텍처
- 네 가지 방식이 모두 반환(semiring)이라는 대수 구조 위의 같은 계산이라는 것을 보인다.
- 반환은 더하기와 곱하기 두 연산을 갖춘 수학 구조다. 질의의 합집합이 더하기, 결합이 곱하기에 대응한다.
- 꼬리표를 다항식으로 두면 출처를 가장 자세하게 담을 수 있다고 제시한다.
- 재귀 질의(datalog)까지 넓혀 형식적 멱급수로 다룬다.
우리 회사와의 관계
- 집계값 하나가 어느 원본 행들의 어떤 조합에서 나왔는지를 수식으로 남기는 출처 기록 구조에 대응할 수 있다.
- T06-11구조대응
Provenance in Databases: Why, How, and Where
한국어 검토 보기
해결 문제
- 데이터베이스는 답을 빨리 내지만 그 답이 왜, 어떻게, 어디서 나왔는지는 설명하지 못한다.
주요 결과
- 신뢰도 계산, 뷰 유지보수와 갱신, 디버깅, 주석 전파에 적용되는 사례를 정리한다.
한계
- 관계형 질의 중심이다. 머신러닝 파이프라인이나 LLM 생성물은 다루지 않는다.
- 실제 시스템에 붙일 때의 저장 비용 문제는 깊이 다루지 않는다.
아키텍처
- 출처 개념을 세 가지로 정리한다.
- why-provenance는 이 결과가 나오게 한 원본 행들의 묶음이다.
- how-provenance는 그 행들이 어떤 방식으로 조합됐는지다. 이 개념의 형식 이론은 10번 Provenance Semirings가 세웠다.
- where-provenance는 결과 값 하나가 원본의 어느 칸에서 복사돼 왔는지다.
- 세 개념 사이의 관계를 형식적으로 비교한다.
우리 회사와의 관계
- 설비 데이터 수집에서 집계값 하나가 어느 태그, 어느 시각, 어느 변환을 거쳐 나왔는지 되짚는 구조에 대응할 수 있다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기