NL-262, Reducing hallucination in structured outputs via Retrieval-Augmented Generation, NAACL industry 2024

다음은 해당 논문 *"RAG를 활용한 구조화된 워크플로우 생성에서의 환각 완화 및 자원 효율적 시스템 구축"*에 대한 요약과 장단점 정리입니다.


📝 논문 요약

배경 및 문제

  • 대형 언어 모델(LLM)은 자연어로부터 구조화된 출력(JSON 워크플로우 등)을 생성할 수 있어 상업적 응용이 활발하다.

  • 그러나 LLM은 환각(hallucination) 문제, 특히 out-of-domain(OOD) 입력에서 신뢰성 없는 출력을 생성하는 경향이 있다.

  • 기업 환경에서는 다양한 사용자 요구에 대응해야 하며, 모델의 크기 및 배포 효율도 중요한 고려사항이다.

제안된 시스템

  • RAG (Retrieval-Augmented Generation) 방식을 활용해, 자연어 요구사항 → JSON 워크플로우 생성 과정의 정확도 향상 및 환각 감소를 달성.

  • 소형 리트리버와 소형 LLM의 조합만으로도 높은 품질의 출력을 생성할 수 있음을 실험적으로 입증.

리트리버 설계

  • 자연어 쿼리와 JSON 객체(단계/테이블) 간의 정렬을 위해 siamese transformer encoder 기반의 리트리버 학습.

  • 다양한 음성 샘플링 전략 적용 (무작위, BM25, ANCE).

  • 파인튜닝된 all-mpnet-base-v2 모델이 최적 성능을 보임 (110M 파라미터 수준으로 매우 경량화됨).

LLM 학습

  • 리트리버가 추천한 테이블/단계 정보를 포함하는 프롬프트로 LLM을 학습 (retriever + LLM = RAG).

  • StarCoderBase 시리즈, CodeLlama, Mistral 등 다양한 크기 및 사전학습 기반 모델 실험.

  • 단순하고 간결한 프롬프트 구조를 채택해 효율적인 학습.

실험 결과

  • RAG 없이 LLM만 사용하면 최대 21%의 환각 발생, RAG 도입 시 단계 환각 7.5% 미만, 테이블 환각 4.5% 미만.

  • 3B RAG 모델이 15.5B 비-RAG 모델보다 성능이 비슷하거나 더 나은 경우도 있어, 소형 모델 기반 시스템의 실용성을 강조.

  • OOD 상황에서도 RAG 기반 모델은 안정적으로 작동 (domain adaptation 없이도 높은 일반화).


✅ 장점 (Strengths)

  1. 환각 감소: RAG 방식 도입만으로도 hallucination 대폭 완화.

  2. 자원 효율성: 소형 리트리버 + 소형 LLM 조합으로도 실전 배포 가능한 성능 확보.

  3. OOD 대응력: 도메인 외 테스트셋에서도 일반화 성능 유지.

  4. 모듈성 확보: 리트리버와 LLM을 독립적으로 학습/관리 가능 → 유연한 시스템 설계.

  5. 실제 배포 가능성 고려: 엔터프라이즈 환경에서의 latency, 배치 처리 등 실무적 고려사항 반영.


❌ 단점 (Limitations)

  1. 리트리버 의존성: 리트리버 추천 품질이 낮으면, LLM의 출력도 크게 저하됨 → recall 보장 필요.

  2. 100% 리콜 가정: LLM 학습 시 "필요한 단계는 항상 추천 목록에 포함된다"는 이상적 가정을 했음.

  3. 복잡한 논리 처리 한계: IF/TRY/FOREACH 등 조건 분기 단계에서 구조 오류 발생.

  4. 리트리버-LLM 공동 학습 미흡: 현재는 별도 학습 구조로, synergy 최대화에는 한계.

  5. 특정 도메인에 최적화: 대부분 IT 워크플로우 중심 데이터로 학습되어 도메인 일반화는 일정 한계 있음.


💡 총평

이 논문은 **GenAI 시스템의 현실적인 한계(환각, 비용, 도메인 일반화)**를 해결하기 위한 작고 효율적인 RAG 기반 시스템 설계를 제시하며, 실제 엔터프라이즈 환경에서의 적용 가능성을 입증했다는 점에서 높은 실용적 가치가 있다. 특히 소형 모델 기반으로도 고성능을 달성할 수 있다는 점은 향후 다양한 산업 분야에서의 GenAI 도입을 가속화하는 데 중요한 참고가 될 수 있다.

Abstract 

생성형 AI(GenAI)의 현재 한계 중 하나는 **환각(hallucination)**을 일으키는 경향입니다. 대형 언어 모델(LLM)이 전 세계적으로 주목받고 있지만, 이러한 환각 문제를 제거하거나 최소한 줄이지 않으면, 실제 환경에서 GenAI 시스템이 사용자에게 널리 채택되기는 어려울 수 있습니다.

우리는 자연어 요구사항으로부터 워크플로우를 생성하는 엔터프라이즈 애플리케이션을 배포하는 과정에서, 해당 워크플로우를 구조화된 출력으로 표현하는 품질을 향상시키기 위해 RAG(Retrieval-Augmented Generation) 방식을 활용한 시스템을 고안했습니다.

우리의 RAG 구현 덕분에, 제안하는 시스템은 환각을 현저히 줄일 수 있었고, LLM이 **도메인 외 입력(out-of-domain)**에도 잘 일반화될 수 있도록 만들었습니다.
또한, 작고 잘 훈련된 retriever를 사용하면 LLM의 크기를 줄일 수 있음을 보여주었으며, 성능 저하 없이도 자원 소모를 줄인 LLM 기반 시스템 배포가 가능하다는 것을 입증했습니다.

1 Introduction

대형 언어 모델(LLM)의 등장으로, 자연어를 코드나 SQL 같은 구조화된 출력으로 변환하는 작업이 상업적으로 실현 가능해졌습니다. 비슷한 응용 사례로는, 자연어 요구사항을 워크플로우로 번역하는 작업이 있습니다. 이 워크플로우는 여러 단계와 그들 간의 논리적 관계를 나타내며, 특정 조건이 만족될 때 자동으로 실행되는 프로세스를 포함합니다. 이러한 자동화는 직원의 생산성을 향상시킵니다.

기업용 시스템은 반복적인 작업을 자동화하고 프로세스를 표준화하는 기능을 제공하지만, 워크플로우를 구성하려면 전문 지식이 필요하기 때문에 진입 장벽이 높습니다. 그러나 생성형 AI(GenAI)는 사용자가 자연어만으로 원하는 작업 흐름을 지정할 수 있게 하여 이 장벽을 낮출 수 있습니다.

하지만 모든 GenAI 응용과 마찬가지로, LLM을 그대로 사용할 경우 신뢰할 수 없는 출력이 생성될 수 있습니다.
실제로 LLM이 **사실이 아닌 정보를 생성하는 현상(환각)**에 대한 대중의 우려가 커졌고, 이에 Cambridge 사전은 2023년 올해의 단어로 "hallucinate"를 선정하기도 했습니다.

이에 대한 해결책으로, 외부 지식이 필요한 작업의 품질을 향상시키기 위해 RAG(Retrieval-Augmented Generation) 기법이 널리 사용되고 있습니다(Gao 외, 2024).

이 논문에서는, 자연어를 워크플로우로 변환하는 상업용 애플리케이션을 개발하는 과정에서 RAG를 적용한 방법을 설명합니다.
워크플로우는 각 단계를 JSON 객체로 구성한 JSON 문서로 표현되며, 각 단계 간의 관계를 명시하는 속성도 포함됩니다.
또한, 워크플로우를 시작하는 조건을 명시하는 트리거(trigger) 단계가 존재할 수 있으며, 경우에 따라 데이터베이스 테이블 이름이 필요하기도 합니다.
이 작업에서의 **환각(hallucination)**은 실제로 존재하지 않는 단계나 테이블 등의 속성을 생성하는 경우를 의미합니다.

충분히 큰 LLM을 파인튜닝하면 어느 정도 양질의 워크플로우를 생성할 수 있지만, 입력이 기존 분포(distribution)에서 벗어난 경우 환각이 발생할 수 있습니다.
기업 사용자들은 각자의 요구에 맞게 애플리케이션을 커스터마이징(예: 새로운 워크플로우 단계 추가) 하기 때문에, 상업용 GenAI 시스템은 이러한 분포 외 입력 문제를 최소화할 수 있어야 합니다.

기업별로 LLM을 각각 파인튜닝할 수도 있지만, 이는 인프라 비용이 매우 높아 현실적이지 않을 수 있습니다.
또한 LLM을 실제 서비스에 배포할 때는 **모델의 크기(자원 소모)**도 중요한 고려사항이므로, 가능한 한 작은 모델을 사용하는 것이 바람직합니다.

  • 기업에선 각자의 요구가 다양하므로, 커스터마이징 해야하는데 학습안하면 OOD에 대한 환각이 잘 일어남
  • 너무 큰 모델을 쓰면 비용적으로 힘듬
  • 여기서 환각은 워크플로우 생성할때, 없는 단계, 테이블의 속성을 생성하는 것을 말함


이 논문의 주요 기여는 다음과 같습니다:

  • 워크플로우 생성이라는 구조화된 출력 작업에 RAG를 적용한 사례를 제시했습니다.

  • RAG를 사용하면 환각이 줄고, 결과 품질이 개선됨을 보였습니다.

  • 아주 작은 retriever 모델과 함께 작은 LLM을 사용해도 성능 저하 없이 시스템을 효율적으로 배포할 수 있음을 입증했습니다.

2 Related Work

3 방법론

그림 2는 우리의 RAG 시스템의 상위 아키텍처를 보여줍니다. 

초기화 단계에서, 리트리버를 이용해 워크플로우 단계(step)와 데이터 테이블(table)의 인덱스를 생성합니다. 사용자가 요청을 제출하면, 리트리버가 호출되어 관련 단계 및 테이블을 추천합니다. 추천된 결과는 사용자 쿼리에 덧붙여져 LLM 프롬프트를 구성합니다. 이후, LLM은 그리디 디코딩을 통해 JSON 형식의 워크플로우를 생성합니다.

우리 시스템을 구축하기 위해, 먼저 자연어와 JSON 객체를 정렬(alignment)하도록 리트리버 인코더를 학습시켰습니다. 

  • 이후, 리트리버의 출력을 프롬프트에 포함시키는 RAG 방식으로 LLM을 학습시켰습니다.
  • 학습된 리트리버로 테이블이나 그런거 가져오는 듯. 사내 RAG 느낌이라 보면될듯

3.1 리트리버 학습

우리는 LLM이 충분한 예제를 통해 워크플로우 단계 간의 관계를 포함한 JSON 문서를 생성하는 방법을 학습할 수 있다고 기대합니다. 할루시네이션(허위 생성) 위험은 주로 단계 이름에서 발생하는데, 이는 가능한 단계가 수만 개에 이르고, 기본 단계가 충분하지 않을 경우 고객이 자신의 단계를 추가할 수 있기 때문입니다. 또한 일부 트리거 단계는 데이터베이스 테이블 이름을 속성으로 요구하는데, 이 테이블 이름도 할루시네이션의 원인이 됩니다.

따라서 우리는 리트리버가 자연어를 기존 단계 및 테이블 이름에 정확히 매핑할 수 있어야 한다고 봅니다.

리트리버 모델을 파인튜닝(fine-tuning)하기로 결정한 데에는 두 가지 이유가 있습니다: 

  • 텍스트와 JSON 객체 간의 매핑을 개선하기 위해서, 
  • 그리고 애플리케이션 도메인에 더 적합한 표현을 생성하기 위해서입니다.

다양한 오픈소스 문장 인코더(Reimers and Gurevych, 2019; Ni et al., 2022)가 존재하지만, 이들은 쿼리와 문서가 동일한 자연어 의미 공간에 있을 때 훈련되었습니다. 반면, 우리의 경우 쿼리는 비정형 자연어이고 JSON 객체는 정형 데이터입니다. 이는 Li et al. (2023b)이 코드 스니펫을 텍스트로 검색한 연구 결과와 일치하며, 도메인 특화 데이터를 통한 파인튜닝이 리트리버 성능을 크게 향상시킨다는 점을 보여줍니다.

우리는 Reimers and Gurevych (2019)와 유사하게 평균 풀링(mean pooling)을 사용하는 시암쌍(siamese) 트랜스포머 인코더를 사용하여 사용자 쿼리와 JSON 객체(단계 또는 테이블)를 고정 길이 벡터로 인코딩합니다. 모델에는 정규화(normalization) 레이어를 포함시켜, 결과 임베딩의 벡터 노름(norm)이 1이 되도록 합니다. 다음과 같이 세 가지 임베딩 vqRn,vsRn,vtRnv_q \in \mathbb{R}^n, v_s \in \mathbb{R}^n, v_t \in \mathbb{R}^n을 생성합니다:

여기서 q,s,tq, s, t는 각각 사용자 쿼리, 단계, 테이블을 의미합니다. 리트리버 RR은 다음과 같이 정의됩니다:

리트리버 모델은 사용자 쿼리와 해당 단계 또는 테이블의 쌍으로 학습됩니다. 테이블 이름은 특정 트리거 유형에 따라 일부 예제에서만 사용되므로, 어떤 쿼리는 테이블과 매핑되지 않을 수 있습니다. 

예를 들어, 그림 1의 워크플로우는 네 개의 단계로 구성되어 있으며, 이는 동일한 쿼리와 각 단계로 이루어진 네 개의 양성 학습 쌍을 형성합니다. 이 중 daily trigger 단계는 테이블 이름이 필요하지 않기 때문에, 이 쿼리는 테이블 리스트가 비어 있습니다.

또한 관련 없는 단계나 테이블을 샘플링하여 음성(negative) 학습 쌍도 생성합니다. 우리는 세 가지 음성 샘플링 전략을 실험했습니다: 무작위, BM25 기반, ANCE 기반(Xiong et al., 2020)입니다.

리트리버는 contrastive loss (Hadsell et al., 2006)를 사용하여 양성 쌍(Y=1Y = 1) 간의 거리를 최소화하고, 음성 쌍(Y=0Y = 0)은 일정 거리 이상 떨어지도록 학습합니다. 쿼리와 단계(또는 테이블) 벡터 간의 코사인 유사도와 거리 D=1cos(sim(vq,vs))D = 1 - \cos(\text{sim}(v_q, v_s))를 기반으로 다음과 같이 contrastive loss LL를 정의합니다:

초기화 단계에서는 FAISS(Douze et al., 2024)를 사용하여 단계 및 테이블의 인덱스를 생성합니다. 사용자가 자연어 쿼리를 제출하면, 이 쿼리를 리트리버로 임베딩한 후 코사인 유사도를 사용하여 요구사항에 가장 적합한 최대 K개의 단계와 테이블을 검색합니다.

3.2 LLM 학습

Lewis et al. (2020)와 같은 엔드투엔드 RAG 시스템과 달리, 우리는 단순함을 위해 리트리버와 LLM을 별도로 학습시키는 방식을 선택했습니다. 먼저 학습된 리트리버를 활용해, 각 예제에 대해 추천된 단계(step) 및 테이블(table) 이름을 포함시켜 데이터셋을 확장합니다. 그런 다음 일반적인 LLM의 지도 학습 방식으로 파인튜닝을 진행합니다.

리트리버의 출력을 JSON 형식으로 LLM 입력에 삽입함으로써, 해당 구조화된 출력 생성 작업을 더 쉽게 만들 수 있습니다. 이는 LLM이 출력 시 관련 JSON 객체를 복사할 수 있기 때문입니다. 

그림 3은 하나의 학습 예제를 보여줍니다. 마지막 네 줄을 제외한 모든 줄이 LLM 프롬프트를 구성하며, 추천된 테이블과 단계는 사용자 쿼리보다 앞에 위치하며 그림에서는 밑줄로 표시되어 있습니다.

가장 자주 사용되는 단계들은 LLM이 스스로 암기할 수 있다고 기대되므로, 이들은 추천 목록에서 제외합니다. 또한, 모든 LLM 학습 예제에서는 리트리버가 100% 리콜(recall)을 달성한다고 가정합니다. 즉, 구조화된 출력을 생성하는 데 필요한 단계와 테이블은 (자주 등장하는 단계를 제외하고) 항상 추천 항목에 포함됩니다.

LLM에게 수천 개의 학습 예제를 보여주고 있기 때문에, 복잡하거나 장황한 프롬프트를 실험할 필요는 없다고 판단했습니다. 그림 3과 유사한 짧고 간결한 형식을 사용하여 입력 토큰 수를 줄이는 동시에, 이 작업이 구조화된 출력 생성임을 명확히 전달할 수 있도록 했습니다. 5.2절에서 보여주듯이, 이러한 접근 방식은 우수한 성능을 보여주었습니다.

이거 근데 환각을 줄인다는게 그냥 RAG을 썼다는거 같은데..?


4 실험

4.1 데이터셋

엔터프라이즈 플랫폼의 내부 배포에서 약 4,000개의 실제 워크플로우 예제를 추출하고, 주석자들이 이에 대한 자연어 요구사항을 작성하도록 했다. 또한, 사용자가 점진적으로 워크플로우를 구성하는 상황을 모델에 학습시키기 위해, 간단하고 적은 단계로 구성된 1,000개의 예제를 규칙 기반으로 생성했다.

시스템이 실제로 배포되었을 때의 품질을 편향 없이 측정하기 위해, 전문가 사용자들이 간단한 UI를 통해 시스템과 상호작용을 시뮬레이션하도록 요청했다. 이 상호작용과 기대되는 JSON 출력을 기반으로 추가적인 데이터셋 분할인 “Human Eval”을 만들었고, 품질과 현실성이 더 높기 때문에 최종 평가는 “Test” 분할 대신 이 데이터를 기준으로 진행했다. 

표 1에는 모든 도메인 내(in-domain) 데이터셋의 통계가 나와 있다. 모든 예제가 트리거를 요구하는 것은 아니며, 일부만 테이블 생성을 필요로 한다.

이러한 라벨링 방식의 한계는 대부분의 내부 데이터가 IT 도메인에 국한되어 있다는 점이다. 반면, 시스템은 HR, 금융 등 다양한 도메인에도 배포될 수 있으므로, 분포 밖(out-of-distribution) 환경에서도 시스템의 품질을 확인할 필요가 있다. 이를 위해, 실제 사용자가 생성한 워크플로우를 포함하는 다른 플랫폼 배포본에서 다섯 개의 추가 데이터셋을 수집하고 주석자들이 라벨링했다.

표 2에는 이 도메인 외 데이터셋의 통계가 나와 있다. 

이들이 훈련 데이터와 얼마나 다른지를 측정하는 기준 중 하나는 “Train” 데이터에 존재하지 않는 단계의 비율이며, 이는 10% 미만에서 70% 이상까지 다양하게 나타난다. 이처럼 큰 차이로 인해, 리트리버 사용과 배포별 인덱스 커스터마이징이 필요하다.

리트리버 인코더 학습을 위해 추출된 4,000개와 규칙 기반으로 생성된 1,000개의 예제로부터 쌍(pair) 데이터를 만들었고, 약 15,000개의 단계 이름 쌍과 1,500개의 테이블 이름 쌍을 구성했다. 이 인코더의 품질은 앞서 언급한 "Human Eval" 분할에서 평가되었다.


4.2 평가 지표

전체 RAG 시스템은 다음 세 가지 지표로 평가되며, 모두 0에서 1 사이의 값을 가진다:

  • Trigger Exact Match (EM): 생성된 JSON 트리거가 정답과 정확히 일치하는지 평가하며, 필요한 경우 테이블 이름도 포함된다.

  • Bag of Steps (BofS): 생성된 JSON 단계와 정답 단계 간의 중복을 순서와 무관하게 측정하는 지표로, bag-of-words 방식과 유사하다.

  • Hallucinated Tables (HT) / Hallucinated Steps (HS): 워크플로우별로 생성된 테이블/단계 중 실제 존재하지 않는 비율을 측정하며, 이 지표는 값이 낮을수록 좋다.

리트리버는 다음 기준으로 평가된다:

  • Recall@15 (단계), Recall@10 (테이블): 자연어 요구사항이 주어졌을 때, 상위 K개로 검색된 단계/테이블이 JSON 정답에 포함된 항목을 얼마나 포괄하는지를 측정한다.


4.3 모델

이 시스템은 실제 운영 환경을 고려하므로, LLM과 리트리버 인코더 모두에서 모델 크기와 성능 간의 균형이 중요하다.

LLM의 경우, 모델 크기가 성능에 미치는 영향을 측정하기 위해 다양한 크기의 모델을 파인튜닝했다. StarCoderBase (Li et al., 2023a)는 JSON과 여러 프로그래밍 언어에 대해 사전학습되어 있으며, 1B, 3B, 7B, 15.5B 버전을 실험했다. 인프라 제약으로 인해 최대 7B 모델만 배포 가능하므로, CodeLlama-7B (Roziere et al., 2023)와 Mistral-7B-v0.1 (Jiang et al., 2023)도 함께 파인튜닝했다. 모든 LLM은 동일한 데이터셋과 하이퍼파라미터를 사용해 학습했다.

리트리버는 all-mpnet-base-v2 모델을 기본으로 사용했다. 이는 파라미터 수가 1.1억 개로 경량이기 때문에 배포에 적합하다. 성능 비교를 위해, 다양한 크기의 GTR-T5 모델(Ni et al., 2022)과도 비교했다.

훈련 관련 세부 사항은 부록 A에 포함되어 있다.

5 결과

5.1 리트리버 인코더

표 3은 "Human Eval" 분할에서 단계와 테이블 검색 성능을 보여준다. GTR-T5처럼 사전학습된 인코더의 크기를 키워도 검색 성능은 크게 향상되지 않았다. 이는 코드 검색에서도 유사하게 관찰된 결과다(Neelakantan et al., 2022). 성능을 눈에 띄게 높이기 위해 가장 효과적인 방법은 인코더의 파인튜닝이었다.

배포 환경을 고려해 가장 작은 크기(110M 파라미터)의 인코더만 파인튜닝했고, 다양한 음성 샘플링 전략을 적용한 결과 all-mpnet-base-v2 모델이 가장 우수한 성능을 보였다.


5.2 검색 기반 생성(RAG)

주요 목표는 할루시네이션을 줄이면서도 인프라 제약 내에서 높은 성능을 유지하는 것이다. 표 4에 따르면, 리트리버 없이 LLM만 파인튜닝했을 경우, "Human Eval" 기준 할루시네이션된 단계 및 테이블 비율이 최대 21%까지 올라간다. 하지만 리트리버를 사용할 경우, 단계는 7.5% 미만, 테이블은 4.5% 미만으로 줄어든다. 모든 모델은 예상 스키마에 따라 유효한 JSON을 생성했다.

리트리버 없이 LLM 크기를 키우면 Bag of StepsTrigger Exact Match가 개선되지만 일관성은 떨어진다. 반면 RAG에서는 크기 증가가 보다 일관된 향상을 보인다. 즉, 더 큰 LLM일수록 검색된 결과를 복사/붙여넣기 방식으로 잘 활용한다는 것을 의미한다.

RAG 파인튜닝된 모델 중 1B 크기의 모델은 상대적으로 많은 할루시네이션을 일으켰다. 7B 모델은 성능과 자원 간 최적의 균형을 보여주었고, 7B와 15.5B 사이의 성능 차이는 미미했다. 특히, 3B RAG 모델은 비-RAG 15.5B 모델보다 Trigger EM과 BofS에서 유사하거나 더 나은 성능을 내면서도 할루시네이션은 적었다. 따라서 인프라가 제한적일 경우 3B RAG 모델도 충분히 실용적이다.

마지막으로, StarCoderBase-7B RAG 모델을 같은 크기의 최신 LLM들과 비교했을 때, CodeLlama-7B 및 Mistral-7B-v0.1은 모든 지표에서 더 나쁜 성능을 보였다. 이는 자연어 중심으로 사전학습된 모델이 이 작업에 오히려 불리할 수 있음을 시사한다.


5.3 도메인 외 평가(OOD Evaluation)

리트리버나 LLM을 추가 학습하지 않고도 OOD 환경에서도 잘 동작하길 원한다. 표 5는 RAG 파인튜닝된 StarCoderBase-7B 모델이 다섯 개의 도메인 외 분할에서 어떻게 작동하는지를 보여준다.

평균적으로, 리트리버 덕분에 OOD 성능은 "Human Eval"과 유사한 수준으로 유지되었다. 각 분할의 샘플 수를 기준으로 가중 평균을 사용했다.

추천 없이 RAG 모델을 평가한 "No RAG Avg." 행에서는 모든 지표가 크게 저하되었다. 다만 Hallucinated Steps는 비슷한 수준을 유지했다. 이는 RAG 모델이 추천이 없을 때 학습 데이터에서 본 단계만 보수적으로 생성하기 때문이며, 테이블은 반대로 더 창의적으로 생성되면서 Hallucinated Tables가 급증했다.


5.4 에러 분석

생성된 워크플로우에서 발생한 오류를 분석한 결과, 리트리버와 LLM 양쪽의 문제로부터 기인한 오류가 존재했다.

사용 빈도가 낮은 단계를 포함한 복잡한 워크플로우의 경우, 중요한 구성 요소가 리트리버의 추천에 없으면 LLM이 제대로 된 출력을 생성하기 어렵다. 리콜을 높이기 위해서는 쿼리를 더 짧게 쪼개서 단계별로 개별 리트리벌을 수행하는 방법이 있다. 이는 현재의 단일 리트리벌 호출 방식 대신, 단계마다 여러 번 호출하는 방식을 의미한다.

또한, LLM이 의도한 구조를 생성하지 못하는 경우도 있었다. 특히 IF, TRY, FOREACH와 같은 워크플로우 논리를 결정하는 단계에서 자주 발생했으며, 이는 어떤 단계가 누락되는지 분석 후 합성 데이터 생성을 통해 보완할 수 있다. 성공/실패 예시는 부록 C에 포함되어 있다.


5.5 엔지니어링 영향

이번 결과는 시스템의 확장성과 모듈성 측면에서 여러 결정에 영향을 미쳤다. 성능이 가장 뛰어난 7B 모델을 선택함으로써 한 GPU로 더 많은 요청을 배치 처리할 수 있게 되었고, 시스템 처리량도 증가했다. 다만 입력 쿼리 길이가 긴 경우, 생성되는 토큰 수도 많아져 대기 시간이 길어지는 경우도 있어, 이는 배치 내 병목이 될 수 있다. 그러나 스트레스 테스트와 사용자 피드백 기준으로는 현재 응답 시간은 수용 가능한 수준이다.

리트리버는 110M 파라미터의 소형 모델을 사용했기 때문에 LLM과 동일 GPU에 함께 배포해도 영향을 거의 미치지 않았고, CPU에서도 충분히 운용 가능하다.

리트리버와 LLM을 별도로 학습했기 때문에, 리트리버는 유사한 데이터 소스를 사용하는 다른 목적에도 재활용 가능하다. 컴포넌트 간 역할이 명확히 분리되어, 서로 독립적으로 최적화할 수 있는 장점도 있다. 다만 학술적 목적에서는 공동 학습(joint training)도 실험해볼 가치가 있다.

응답 시간을 줄이기 위한 향후 아이디어로는 다음이 있다:

  • JSON 대신 YAML로 구조화된 출력을 생성해 토큰 수 절감

  • speculative decoding 기법 도입 (Leviathan et al., 2023; Chen et al., 2023; Joao Gante, 2023)

  • 전체 워크플로우 대신 단계별로 스트리밍 응답 제공

6 결론

우리는 구조화된 출력 작업에서 할루시네이션을 줄이고 일반화를 가능하게 하기 위해 검색 기반 LLM(RAG)을 활용하는 접근 방식을 제안한다. 할루시네이션 감소는 실제 GenAI 시스템의 채택을 위해 필수적이며, RAG를 통해 작은 리트리버와 소형 LLM만으로도 자원이 제한된 환경에서 시스템을 배포할 수 있음을 보여준다. 향후 연구로는 리트리버와 LLM 간의 시너지를 높이기 위한 공동 학습이나 양자 간 협업을 촉진하는 모델 아키텍처 개선이 있다.





Reference

댓글