연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
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 보고서 기능과 업무 실행 에이전트가 다루는 대용량 설비 로그, 장기간 생산 이력을 통째로 읽는 대신 코드로 훑고 부분 질의하는 구조로 대응할 수 있다.
- T02-2구조대응
RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval
한국어 검토 보기
해결 문제
- 검색 기반 생성(RAG)이 짧은 토막만 가져오다 보니 문서 전체 맥락을 놓친다.
핵심 구조
- 문서 조각을 벡터로 만들고, 비슷한 것끼리 묶고, 묶음을 요약한다. 이 과정을 반복해 요약 트리를 아래에서 위로 쌓는다.
- 질문이 오면 트리의 여러 층에서 함께 검색한다. 세부 사실과 전체 요약을 같이 쓴다.
주요 결과
- 여러 단계 추론이 필요한 질의응답에서 기존 검색 방식보다 크게 좋았다.
- GPT-4와 붙여 QuALITY 벤치마크 최고 성능을 절대 정확도 20%p 끌어올렸다.
한계
- 트리를 미리 만들어야 한다. 문서가 자주 바뀌면 다시 만드는 비용이 든다.
- 요약 단계에서 정보가 깎일 수 있다. 숫자나 코드값처럼 정확해야 하는 항목에 불리하다.
우리 기능과의 연결
- AI 기준정보 생성에서 품목, 공정, BOM 문서 뭉치를 계층 요약으로 정리해 두고 층별로 찾는 구조에 대응할 수 있다.
- T02-3유사문제
Walking Down the Memory Maze: Beyond Context Limit through Interactive Reading (MemWalker)
한국어 검토 보기
해결 문제
- 문맥창을 무작정 늘리지 않고 긴 문서를 읽는 방법.
핵심 구조
- 긴 문서를 요약 노드의 트리로 만든다.
- 모델이 읽는 주체가 되어 트리를 위에서 아래로 타고 내려간다. 필요한 가지만 골라 펼친다.
- 답에 쓰인 원문 구간을 짚어준다.
주요 결과
- 긴 문서 질의응답에서 문맥창 확장, 순환 구조, 검색 방식보다 좋았다.
- 어떤 경로로 답을 찾았는지 보이므로 설명이 쉽다.
한계
- 트리를 잘못 타면 되돌아가기 어렵다.
- 문서 하나 단위 실험이다. 여러 문서를 가로지르는 질의는 다루지 않았다.
우리 기능과의 연결
- 영상 안전 판단 로그나 장기 알람 이력에서 원인 구간을 짚어 보여줘야 할 때, 근거 위치를 남기는 탐색 구조로 대응할 수 있다.
- T02-4후보
MemGPT: Towards LLMs as Operating Systems
한국어 검토 보기
해결 문제
- 문맥창이 작아서 긴 대화와 큰 문서를 다루지 못하는 문제.
핵심 구조
- 운영체제의 메모리 계층을 흉내 낸다. 빠른 메모리(문맥창)와 느린 메모리(외부 저장소)를 나눈다.
- 모델이 스스로 무엇을 문맥창에 올리고 무엇을 내릴지 결정한다.
- 인터럽트로 제어 흐름을 관리한다.
주요 결과
- 문맥창을 훨씬 넘는 대용량 문서를 분석했다.
- 여러 회차에 걸친 대화에서 이전 내용을 기억하고 갱신하는 에이전트를 만들었다.
한계
- 심사를 거친 학회 발표본이 아니다.
- 메모리를 옮기는 판단 자체를 모델이 하므로, 판단이 틀리면 정보가 사라진다.
- 호출 횟수가 늘어 지연과 비용이 커진다.
우리 기능과의 연결
- 업무 실행 에이전트가 며칠에서 몇 주에 걸친 작업 맥락을 유지해야 할 때 쓸 수 있는 메모리 계층 구조 후보다.
- T02-5구조대응
Chain of Agents: Large Language Models Collaborating on Long-Context Tasks
한국어 검토 보기
해결 문제
- 입력을 줄이는 검색 방식은 필요한 부분을 놓칠 수 있다. 문맥창을 늘리는 방식은 중요한 부분에 집중하지 못한다.
핵심 구조
- 긴 글을 여러 토막으로 나눈다. 작업자 에이전트가 토막을 하나씩 맡아 순서대로 읽고 앞사람 결과를 넘겨받는다.
- 마지막에 관리자 에이전트가 모아서 최종 답을 만든다.
- 읽기와 추론을 번갈아 한다. 각 에이전트의 문맥창은 작게 유지한다.
주요 결과
- 질의응답, 요약, 코드 완성에서 검색 방식과 전체 문맥 투입 방식 대비 최대 10% 향상.
한계
- 순차 처리라서 토막 수가 늘면 지연이 선형으로 커진다.
- 앞 단계에서 정보를 놓치면 뒤로 전달되지 않는다.
우리 기능과의 연결
- 제조 AI 분석에서 여러 설비, 여러 라인의 긴 데이터를 구간별로 나눠 처리하고 마지막에 합치는 구조에 대응할 수 있다.
- T02-6유사문제
Lost in the Middle: How Language Models Use Long Contexts
한국어 검토 보기
해결 문제
- 문맥창이 길어졌다고 해서 모델이 그 안의 정보를 잘 쓰는지는 확인되지 않았다.
핵심 구조
- 논문이 새 모델을 제안하지 않는다. 평가 연구다.
- 여러 문서 질의응답과 키값 검색 두 과제에서, 정답이 들어있는 위치를 앞, 중간, 뒤로 옮겨가며 성능을 잰다.
주요 결과
- 정답이 맨 앞이나 맨 뒤에 있을 때 성능이 가장 높다.
- 정답이 중간에 있으면 성능이 크게 떨어진다. 긴 문맥 전용 모델도 마찬가지다.
한계
- 2023년 시점 모델 기준이다. 최신 모델에서 정도는 달라질 수 있다.
- 합성 과제 위주라 실제 업무 문서와 차이가 있다.
우리 기능과의 연결
- 설비 데이터 수집 결과를 그대로 길게 넣으면 가운데 구간이 무시될 수 있다는 위험을 보여준다. 프롬프트 배치 설계에 직접 걸리는 문제다.
- T02-7유사문제
RULER: What's the Real Context Size of Your Long-Context Language Models?
한국어 검토 보기
해결 문제
- 건초더미에서 바늘 찾기(NIAH) 같은 단순 검색 시험은 긴 문맥 능력을 제대로 못 잰다.
핵심 구조
- 길이와 난이도를 조절할 수 있는 합성 벤치마크를 만든다.
- 바늘을 여러 개 두거나, 여러 단계를 거쳐야 풀리는 과제, 정보를 모아 종합해야 하는 과제를 넣는다.
주요 결과
- 17개 긴 문맥 모델을 쟀다. 대부분 NIAH는 거의 만점이다.
- 그런데 길이가 늘면 성능이 크게 떨어진다. 32K를 지원한다고 광고하는 모델 중 절반만 32K에서 쓸 만했다.
한계
- 합성 과제다. 실제 문서 이해와 다를 수 있다.
- 영어 위주 평가다.
우리 기능과의 연결
- 우리 기능에 쓸 모델을 고를 때 "몇 K 지원"이라는 광고 숫자 대신 실제 유효 길이를 재는 기준으로 쓸 수 있다.
- T02-8후보
LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression
한국어 검토 보기
해결 문제
- 긴 프롬프트는 비용과 지연이 크다. 위치에 따라 성능이 흔들리는 문제도 있다.
핵심 구조
- 질문과 관련된 정도를 재서 중요한 토막과 토큰만 남긴다. 나머지는 지운다.
- 문서 순서를 다시 배치해 중요한 내용이 좋은 위치에 오게 한다.
주요 결과
- NaturalQuestions에서 토큰을 4분의 1로 줄이고도 성능이 최대 21.4% 올랐다.
- LooGLE에서 비용을 94% 줄였다.
- 1만 토큰 정도를 2배에서 6배로 압축할 때 전체 지연이 1.4배에서 2.6배 빨라졌다.
한계
- 압축을 하려면 작은 모델을 한 번 더 돌려야 한다.
- 지워진 토큰은 복구되지 않는다. 정확한 수치나 코드값이 날아갈 위험이 있다.
우리 기능과의 연결
- QFactory MES에서 뽑은 대량 이력을 AI 보고서에 넣기 전 비용을 줄이는 전처리 후보다. 다만 수치 정확도 검증이 먼저다.
- T02-9구조대응
Recursively Summarizing Books with Human Feedback
한국어 검토 보기
해결 문제
- 사람이 다 읽기 어려운 분량의 글을 모델이 요약하게 만들고, 그 결과를 사람이 어떻게 평가할 것인가.
- 소설 한 권 분량은 문맥창에 들어가지 않는다.
핵심 구조
- 작업 쪼개기(재귀 분해)를 쓴다. 책을 구간으로 나눠 각 구간을 먼저 요약한다.
- 그 요약들을 다시 묶어 요약한다. 이 과정을 위로 반복해 책 전체 요약을 만든다.
- 각 단계마다 사람 피드백으로 학습한다. 사람은 책 전체를 읽지 않고 해당 구간만 보고 평가한다.
주요 결과
- BookSum 데이터셋에서 당시 최고 성능을 냈다.
- 생성 요약의 약 5%가 사람이 쓴 요약 수준으로 평가됐다.
- 이 요약을 쓴 질의응답 모델이 NarrativeQA에서 당시 최고 성능을 냈다.
한계
- 심사를 거친 학회 발표본이 아니다.
- 사람 라벨링 비용이 크다.
- 요약을 쌓아 올리므로 아래 단계에서 놓친 사실은 위로 전달되지 않는다.
- 소설 대상 실험이다. 숫자와 코드값이 많은 기술 문서와는 성격이 다르다.
우리 기능과의 연결
- 긴 글을 쪼개서 재귀로 요약하는 방식의 원조 논문이다. 1번 RLM, 2번 RAPTOR, 3번 MemWalker의 계보가 여기서 시작한다.
- AI 보고서에서 장기간 생산 이력을 구간별로 요약해 위로 합치는 구조에 대응할 수 있다.
- T02-10후보
Efficient Streaming Language Models with Attention Sinks (StreamingLLM)
한국어 검토 보기
해결 문제
- 대화가 계속 이어지거나 입력이 끝없이 들어오는 상황에서 모델이 메모리를 감당하지 못한다.
- 앞쪽 토큰을 그냥 버리면 성능이 무너진다.
핵심 구조
- 관심 싱크(attention sink) 현상을 찾아냈다. 모델이 맨 앞 토큰 몇 개에 뜻과 무관하게 높은 가중치를 준다.
- 그래서 맨 앞 토큰 몇 개는 계속 남겨두고, 나머지는 최근 구간만 유지한다.
- 다시 학습시키지 않고도 무한히 긴 입력을 흘려보낼 수 있다.
주요 결과
- Llama-2, MPT, Falcon, Pythia를 수백만 토큰까지 처리하게 만들었다.
- 창을 밀며 매번 다시 계산하는 방식 대비 최대 22.2배 빨랐다.
- 사전학습 때 전용 싱크 토큰을 두면 더 좋아졌다.
한계
- 오래된 구간은 실제로 버린다. 긴 입력 전체를 기억하는 것이 아니다.
- 앞뒤로 멀리 떨어진 내용을 이어 붙여야 하는 질문에는 맞지 않는다.
- 모델 내부 구현을 손대야 한다. 상용 API 모델에는 그대로 적용할 수 없다.
우리 기능과의 연결
- 이 목록에서 검색과 에이전트가 아니라 모델 자체가 긴 입력을 어떻게 버티는지 다루는 첫 항목이다.
- 설비 데이터가 끊임없이 들어오는 실시간 감시 쪽에 붙일 수 있는 후보다.
- T02-11유사문제
LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding
한국어 검토 보기
해결 문제
- 긴 문맥 능력을 실제 과제로 재는 기준이 없다.
- 영어만 재는 벤치마크로는 다른 언어 성능을 알 수 없다.
핵심 구조
- 6개 과제 갈래에 21개 데이터셋을 모았다. 영어와 중국어 두 언어로 만들었다.
- 과제는 단일 문서 질의응답, 다중 문서 질의응답, 요약, 소수 예시 학습, 합성 과제, 코드 완성이다.
- 평균 길이는 영어 6,711 단어, 중국어 13,386 자다.
주요 결과
- 상용 모델(GPT-3.5-Turbo-16k)이 공개 모델보다 좋았다.
- 위치 임베딩을 늘려 문맥을 확장하는 방식이 도움이 됐다.
- 검색으로 압축해 넣는 방식은 약한 모델에는 도움이 되지만, 원래 긴 문맥을 잘 다루는 모델보다는 못했다.
한계
- 두 언어는 영어와 중국어다. 한국어는 없다.
- 2023년 시점 모델 기준이다. 지금 모델은 상당수 과제에서 점수가 올라가 변별력이 떨어질 수 있다.
우리 기능과의 연결
- 7번 RULER와 짝이다. RULER는 합성 과제로 유효 길이를 재고, 이쪽은 실제 문서 과제로 잰다. 둘을 같이 봐야 한다.
- 한국어 문서를 다루는 우리 상황에서는 영어 단일 벤치마크보다 다국어 벤치마크의 설계 방식이 참고가 된다. 다만 한국어 항목은 직접 만들어야 한다.
- T02-12후보
Ring Attention with Blockwise Transformers for Near-Infinite Context
한국어 검토 보기
해결 문제
- 트랜스포머는 입력이 길어지면 메모리가 급격히 늘어 장치 한 대에 담기지 않는다.
- 근사나 정보 손실 없이 문맥 길이를 늘리고 싶다.
핵심 구조
- 입력을 블록으로 잘라 여러 장치에 나눠 올린다.
- 각 장치가 자기 블록을 계산하는 동안, 옆 장치로 키값 블록을 고리처럼 돌려보낸다.
- 통신과 계산을 겹쳐서 돌리므로 추가 지연이 거의 없다.
주요 결과
- 이전의 메모리 절약 기법 대비 장치 수만큼 긴 입력을 다룰 수 있다고 보고한다.
- 수백만 토큰 규모 문맥으로 언어모델링과 강화학습 실험을 했다.
- 계산을 근사하지 않는다. 결과가 원래 attention과 같다.
한계
- 심사를 거친 학회 발표본이 아니다.
- 장치를 여러 대 붙여야 효과가 난다. 하드웨어 비용이 든다.
- 모델 학습과 추론 구현을 직접 손대야 한다. API로 쓰는 모델에는 적용할 수 없다.
우리 기능과의 연결
- 10번 StreamingLLM과 함께 모델 구조 쪽 공백을 메우는 항목이다. 10번은 오래된 구간을 버리고 가고, 이쪽은 나눠서 다 들고 간다.
- 우리가 모델을 직접 학습하거나 사내 서버에 올릴 경우의 후보다. 지금처럼 API 모델을 쓰는 동안은 배경 지식에 가깝다.
- T02-13후보
Extending Context Window of Large Language Models via Positional Interpolation
한국어 검토 보기
해결 문제
- 회전 위치 인코딩(RoPE)을 쓰는 모델은 학습한 길이를 넘어가면 성능이 무너진다.
- 검색이나 요약으로 우회하지 말고 문맥창 자체를 늘리고 싶다.
핵심 구조
- 위치 번호를 학습 범위 밖으로 밀어내지 않는다. 입력 위치 번호를 원래 문맥창 범위 안으로 선형 축소한다. 이것이 위치 보간이다.
- 축소한 상태로 아주 짧게 추가 학습을 한다.
주요 결과
- LLaMA 7B에서 65B까지 문맥창을 32768 토큰으로 늘렸다. 추가 학습은 1000스텝 이내다.
- 보간의 오차 상한이 그냥 밖으로 늘리는 방식보다 약 600배 작다는 이론 분석을 붙였다.
- 암호 찾기, 언어 모델링, 문서 요약에서 잘 동작했고 원래 길이 과제 성능도 대체로 지켰다.
한계
- 심사를 거친 학회 발표본이 아니다.
- 모델 가중치를 직접 손봐야 한다. API로 쓰는 모델에는 적용할 수 없다.
- 문맥창을 늘려도 6번 Lost in the Middle이 지적한 가운데 구간 무시 문제는 따로 남는다.
우리 기능과의 연결
- 이 목록에서 문맥창을 실제로 늘리는 갈래를 대표하는 항목이다. 나머지는 대부분 우회하거나 버리거나 압축한다.
- 사내 서버에 모델을 직접 올릴 경우의 후보다.
- T02-14후보
Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention
한국어 검토 보기
해결 문제
- 끝없이 긴 입력을 정해진 메모리 안에서 처리하고 싶다.
- 오래된 구간을 그냥 버리면 뒤에서 필요할 때 되살릴 수 없다.
핵심 구조
- 기존 attention 블록 안에 압축 메모리를 넣는다.
- 한 블록에서 가까운 구간을 보는 지역 attention과 오래된 구간을 보는 장기 attention을 같이 돌린다.
- 밀려난 키값을 버리지 않고 압축 메모리에 눌러 담아 계속 쓴다.
주요 결과
- 1B에서 8B 모델로 100만 토큰 암호 찾기와 50만 토큰 책 요약을 처리했다.
- 메모리 사용량이 길이와 무관하게 일정 수준에 묶인다.
- 흘려보내는 방식의 추론이 가능하다.
한계
- 심사를 거친 학회 발표본이 아니다.
- 압축이므로 원문을 그대로 복원하지 못한다. 숫자나 코드값 같은 정확한 항목은 뭉개질 수 있다.
- 모델 구조와 학습을 직접 손봐야 한다.
우리 기능과의 연결
- 10번 StreamingLLM은 오래된 구간을 버리고, 12번 Ring Attention은 장치를 늘려 다 들고 가고, 이쪽은 눌러 담아 들고 간다. 같은 모델 구조 갈래의 세 번째 답이다.
- 설비 데이터가 끊임없이 들어오는 실시간 감시에서, 오래된 이력을 완전히 버리기 곤란할 때의 후보다.
- T02-15후보
H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models
한국어 검토 보기
해결 문제
- 글을 생성하는 동안 모델은 앞서 계산한 키값(KV) 캐시를 계속 쌓아둔다. 입력이 길수록 이 캐시가 메모리를 다 잡아먹는다.
핵심 구조
- attention 점수의 대부분을 아주 적은 수의 토큰이 차지한다는 것을 관찰했다. 이 토큰을 자주 등장하는 큰손(heavy hitter)이라 부른다.
- 최근 토큰과 큰손 토큰만 캐시에 남기고 나머지는 버린다.
- 무엇을 버릴지 고르는 문제를 동적 최적화 문제로 정리해 푼다.
주요 결과
- OPT, LLaMA, GPT-NeoX에서 처리량이 기존 추론 시스템 대비 최대 29배 늘었다.
- 지연은 최대 1.9배 줄었다.
한계
- 버린 캐시는 되살릴 수 없다. 뒤에서 그 구간이 필요해지면 답이 나빠진다.
- 추론 엔진 내부를 손봐야 한다. API로 쓰는 모델에는 적용할 수 없다.
우리 기능과의 연결
- 8번 LongLLMLingua는 모델에 넣기 전 입력 글자 수를 줄인다. 이쪽은 모델 안에서 캐시를 줄인다. 압축이라는 말은 같지만 층이 다르다.
- 사내 GPU 서버로 긴 이력을 돌릴 때 추론 비용을 줄이는 후보다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기