CAE 기술 문서 질의응답 환경에서 청크 기반 RAG는 문서 구조와 검색 단위 간 

불일치로 인해 한계를 보인다. 기술 동향 1회에서는 기존 RAG 방식의 문제점을, 

2회에서는 제안 아키텍처와 검증 결과를 다룬다.

 

3. 전환 - 대조 실험, 원인 규명 그리고 LAR의 설계

(1) 결정적 계기 : 동일 소스 기반한 대조 실험

자체 구축한 Ollama 기반 RAG 시스템의 답변 품질을 검증하는 과정에서, 동일한 Markdown(MD) 파일 소스 세트를 NotebookLM에 업로드하여 동일한 질의를 수행하였다. 그 결과 자체 시스템의 답변 품질이 내부 평가 기준 55점 수준이었던 반면, Notebook LM은 동일한 소스를 기반으로 약 88점 수준의 답변을 생성하였다. 소스가 동일하므로 데이터 품질은 변인에서 제거된 상태였다. 33점의 격차는 순수하게 파이프라인과 모델의 차이에서 나온 것이었다.

(2) 가설 검증 과정

품질 격차의 원인을 규명하기 위해 다음과 같은 두 가지 가설을 설정하였다.

•가설 1 : “NotebookLM은 Google의 사전학습 지식을 활용하여 소스의 결손 정보를 보완하는가?” 이 가설은 기각되었다. NotebookLM은 업로드된 문서를 기반으로 답변을 생성하는 grounded 방식으로 동작하며, 사전학습된 일반 지식을 활용하여 소스에 없는 정보를 임의로 보완하는 구조가 아니기 때문이다.

•가설 2 : “품질 격차는 검색 단위와 모델 규모의 결합에서 발생하는가?” 두 시스템의 구조적 차이를 비교한 결과, 이 가설이 가장 타당한 설명으로 확인되었다. 자체 시스템은 검색된 4개의 청크를 8~14B 규모의 소형 로컬 모델에 전달하는 구조인 반면, NotebookLM은 사실상 문서 전문에 가까운 대규모 컨텍스트를 100만 토큰급 컨텍스트 윈도우를 가진 대형 모델(Gemini)에 제공한다.

즉, NotebookLM의 우위는 특정한 검색 기술의 차별성에 있는 것이 아니라, 대규모 컨텍스트 처리 능력을 가진 모델이 문서 전체를 직접 참조할 수 있는 구조에서 비롯된 것으로 해석할 수 있다. 2장에서 확인한 청크 경계에 의한 의미 단위 절단, 유사도 기반 검색의 한계, 종합형 질의 대응의 취약성 등 기존 접근의 실패 원인은 모두 이 하나의 구조적 차이로 설명된다. 청크를 사용하지 않으면 청크 경계에서 발생하는 의미 손실이 사라지고, 분할된 문서를 검색하는 과정이 없으면 검색 대상 선정 실패의 가능성도 제거된다. 또한 문서 전체가 모델의 컨텍스트에 포함되면 서로 다른 위치에 분산된 정보의 연결과 종합은 별도의 검색 과정이 아니라 LLM 자체의 문맥 이해 능력으로 처리된다.

(3) 제약 조건의 재해석: 청킹은 왜 ‘당연’해 보였는가

“처음부터 전체 주입(full-document injection)을 고려하지 않았을까”라는 관점에서 초기 설계를 다시 검토하였다. 당시 일반적인 하드웨어 기준인 4 GB VRAM 환경에서는 로컬 모델의 컨텍스트 윈도우가 제한적이었고, 수만 페이지 규모의 문서를 처리하기 위해 청킹은 선택 가능한 방법이 아니라 필수적인 설계 조건으로 인식되었다.

돌이켜 보면 청크 기반 RAG는 이 프로젝트에서 최적의 해법으로 선택된 것이 아니었다. 제한된 하드웨어 환경이라는 제약과 ‘업계 표준’이라는 방법론적 관성이 결합되어 청킹이라는 전제를 당연하게 받아들였던 것이다. RAG에서 청킹은 제한된 컨텍스트 윈도우 문제를 해결하기 위한 효과적인 방법이지만, 장문 컨텍스트 모델의 등장으로 인해 해당 제약 자체가 완화되면서 청킹이 반드시 필요한 문제인지 다시 검토할 필요가 생겼다. 이는 이후 확인한 관련 선행 연구들이 제기한 문제의식과도 일치한다.

이에 대한 해결 방향은 명확하였다. 보안 요구사항에 따라 지식 자산(MD 파일)은 로컬에 유지하되, 추론 과정에서는 장문 컨텍스트 처리가 가능한 모델(Gemini, 최대 100만 토큰 컨텍스트)에 필요한 문서를 직접 전달하는 구조를 적용하는 것이다. 실측 결과 하나의 주제 폴더에 포함된 MD 파일 전체 용량은 약 0.4 MB, 약 10만 토큰 수준으로, 폴더 단위 전문 주입을 수행하더라도 컨텍스트 한도 내에서 충분한 여유가 있었다. 이를 통해 기존에 당연하게 받아들였던 “문서는 반드시 청킹해야 한다”는 설계 가정을 재검토하게 되었다.

정밀한 조각 검색은 컨텍스트가 제한된 환경에서 필요한 최적화 기법이다. 반대로 문서 전문을 직접 주입할 수 있다면, 관련 정보를 포함한 조각을 선별하는 검색 문제 자체가 제거된다. 이에 따라 기존 검색 문제를 해결하기 위해 필요했던 임베딩 모델(bge -m3), 벡터 데이터베이스(ChromaDB), 청킹 스크립트, 재인덱싱 절차 등 전체 검색 인프라가 더 이상 필수 구성 요소가 아니게 되었다.

이러한 구조적 단순화는 저사양 환경에서 두 가지 효과를 가져왔다. 첫째, 로컬 컴퓨팅 자원을 다른 작업에 활용할 수 있게 되었다. 둘째, 원본 문서 변경 시 반복적으로 수행해야 했던 벡터 인덱스 재구축 과정이 사라져 유지관리 부담이 크게 감소하였다. 결국 LAR로의 전환은 새로운 검색 기술을 추가한 결과가 아니라, 장문 컨텍스트 모델을 활용할 수 있게 되면서 기존 청크 기반 RAG를 유지할 필요성이 사라졌기 때문에 자연스럽게 도출된 결과였다.

또 하나의 중요한 효과는 초기 설계 목표의 완성이다. 최종 아키텍처에서 로컬 환경에 남은 구성요소는 MD 파일 저장소와 경량 Streamlit 인터페이스뿐이며, GPU를 요구하는 구성요소는 존재하지 않는다. 임베딩 계산, 로컬 추론, 벡터 검색 연산이 모두 제거되었기 때문이다. 이는 시스템이 GPU 탑재 여부와 관계없이 일반적인 업무용 PC 환경에서 동일한 방식으로 운용될 수 있음을 의미한다. 또한 추론 모델을 무료 API 환경에서 활용함으로써[호출 제한 대응 방안은 3장 (4)절에서 설명], 시스템 구축 비용 역시 사실상 최소 수준으로 낮출 수 있었다.

결과적으로 저사양 하드웨어의 제약에서 출발한 설계는, 하드웨어 성능을 극한으로 최적화하는 방향이 아니라 성능이 필요한 로컬 구성요소 자체를 구조적으로 제거하는 방향으로 문제를 해결하였다. 이는 “해석 엔지니어 누구나 자신의 노트북에서 구축·운용할 수 있는 챗봇”이라는 초기 목표를 달성한 핵심 원리였다.

(4) LAR 아키텍처의 설계

이상의 분석을 바탕으로 최종 아키텍처를 도출하였다. 전체 파이프라인은 PDF → MD → JSON → Chatbot의 4단계 구조로 구성되며, 단계별 설계 원칙은 다음과 같다.

•첫째, 지식 표현의 이원화 : MD는 지식 자산(Asset)으로 정의한다. Gemini Flash의 비전 기반 변환기를 활용하여 생성된 MD는 수식, 표, 키워드 문법 구조를 보존하며, 영구 보관되고 사람이 직접 검증 가능한 재사용 가능한 원천 데이터로 활용된다. 반면 JSON은 실행 인덱스(Execution Index)로 정의한다. 각 MD 파일의 주제, 포함 키워드, 요약 정보를 담는 JSON 인덱스는 MD로부터 언제든 재생성 가능한 파생 데이터이며, 실행 시점에서 적합한 파일을 선택하는 용도로만 사용된다. 이러한 분리를 통해 인덱스 스키마나 생성 프롬프트를 개선하더라도 지식 자산 전체를 재구축할 필요가 없으며, 데이터 품질 검증의 기준점 역시 MD로 단일화된다.

•둘째, 검색 주체의 전환 : 기존 임베딩 기반 유사도 검색을 대신하여, LLM 자체가 JSON 인덱스를 분석하고 질의에 적합한 파일을 추론적으로 선택한다(LLM-as-Retriever). 2장 (3)절에서 확인한 임베딩 검색의 한계, 즉 수식·표 구조에 대한 변별력 부족과 정보 완전성 평가의 어려움은 자연어 기반 인덱스를 해석하는 LLM 선택 과정에서는 상대적으로 완화된다. 파일 선택은 단순히 벡터 공간상의 근접성을 찾는 과정이 아니라, “질문의 답이 어떤 문서에 존재할 가능성이 높은가”를 판단하는 추론 과정으로 전환된다. 또한 선택 과정의 근거가 자연어 형태로 남기 때문에, 검색 실패 시 원인 분석과 개선도 가능하다.

•셋째, 검색 단위의 확장 : 선택된 파일은 청크 단위가 아니라 문서 전체를 하나의 컨텍스트로 모델에 제공한다. 2장 (4)절에서 확인했듯이 FEM 문서는 인간 저자가 이미 Guide–Chapter–Lesson의 계층 구조를 기반으로 의미 단위를 구성해 놓은 자료이다. 따라서 이를 인위적으로 재분할하기보다 기존 구조를 유지한 채 활용하는 것이 더 효과적이었다. 이에 따라 수식 유도 과정은 연속된 흐름으로 유지되고, 표는 원래 구조 그대로 보존되며, 상호참조 관계를 갖는 키워드 정의 역시 동일한 컨텍스트 내에서 모델에 전달된다.

•넷째, 방어적 운영 설계 : 앞의 세 가지 원칙이 시스템 구조에 관한 결정이라면, 네 번째 원칙은 실제 운용 환경에서 답변 신뢰성을 확보하기 위한 운영 설계이다. 모델 출력 언어를 한국어로 고정하고, 답변 내용을 소스 기반 정보([자료])와 모델의 일반 지식 또는 추론 기반 정보([추론])로 구분하도록 프롬프트를 구성하였다. 특히 출처 태그는 환각을 완전히 제거하는 방식이 아니라, 환각 가능성을 사용자에게 투명하게 노출하고 검증 가능성을 높이는 실용적 제어 방식이다.

이러한 설계 원칙을 기반으로 반복적인 개선을 거쳐 현재의 Abaqus LAR-chatbot을 구축하였으며, 이후 동일한 파이프라인을 내구해석 전문 도구인 Fe- safe에도 적용해 동일 도메인 내 확장 가능성을 확인하였다.

(5) 지식 자산의 구축: PDF → MD 변환기의 진화

LAR에서는 검색 계층을 제거했기 때문에 답변 품질이 파일 선택의 정확도와 MD 지식 자산 자체의 품질에 의해 결정된다. 특히 MD는 2장 (1)절에서 확인한 바와 같이 전체 파이프라인의 품질 상한선을 결정하는 핵심 요소이며, 이에 따라 PDF → MD 변환기는 챗봇 본체보다 중요한 기반 소프트웨어로 자리 잡았다. 본 프로젝트에서 변환기가 챗봇 시스템 자체보다 더 많은 개발 반복을 거친 이유도 여기에 있다. 변환기의 발전 과정은 크게 네 세대로 구분할 수 있다.

•1세대 - 텍스트 레이어 기반 추출

1세대 방식은 순수한 텍스트 추출 방식이었다. pdfplumber와 PyMuPDF의 텍스트 레이어 추출 기능에 의존한 이 방식은 2장 (1)절에서 설명한 바와 같이 수식과 표 처리에서 구조적 한계를 보였다. 추출 도구를 변경하더라도 문제는 해결되지 않았으며, 텍스트 레이어 기반 접근만으로는 기술 문서의 핵심 요소인 수식과 표를 누락 없이 보존하는 것이 원리적으로 어렵다는 결론에 도달하였다. 이에 따라 일부 누락 정보를 ‘원본 페이지 참조’ 형태로 표시하는 보완 방식도 검토하였으나, 근본적인 해결책은 아니었다.

•2세대 - Vision LLM 기반 변환

2세대에서는 접근 방식을 근본적으로 변경하였다. 페이지를 텍스트로 직접 파싱하는 대신 이미지로 렌더링한 후 Vision LLM(Claude Haiku 4.5)이 사람과 같이 시각적으로 문서를 해석하도록 하였다. 이 방식은 수식을 LaTeX 형식으로 변환하고, Mark-down 표 구조로 보존하며, 그림은 텍스트 설명으로 변환할 수 있었다. 또한 PDF 내부 텍스트 레이어의 품질과 관계없이 동작하므로 정보 누락 최소화 측면에서 높은 성능을 보였다.

그러나 모든 페이지를 Vision 처리하는 방식은 비용 측면의 한계를 갖고 있었다. 253페이지 문서를 기준으로 전체 페이지를 Vision API로 처리하는 데 약 1달러가 소요되었으며, 수만 페이지 규모의 문서군 전체에 적용하기에는 비용 부담이 있는 방식이었다.

•3세대 - 품질 평가 기반 하이브리드 변환

3세대에서는 비용과 품질을 동시에 확보하기 위해 하이브리드 전략을 도입하였다. calculate_quality_score() 함수는 페이지별로 수식 기호 밀도, Figure 캡션 존재 여부, 이미지 영역 비율, 표 패턴, 비정상 텍스트 발생 여부를 분석해 품질 점수를 계산한다. 이후 점수가 임계값(QUALITY_SCORE_THRESHOLD =3) 이상인 페이지는 Vision 처리로 전환하고, 기준 미만인 페이지는 PyMuPDF 기반의 저비용 텍스트 추출 방식으로 처리하였다.

그 결과 253페이지 문서 기준 Vision API 호출 횟수는 253회에서 50~80회 수준으로 감소하였으며, 처리 비용도 약 80 % 절감되었다.

반면 하이브리드 방식은 문서 특성에 따른 새로운 튜닝 문제를 야기했다. 초기 구현에선 분기 기준으로 사용한 임계값(FIGURE_TEXT_THRESHOLD, 초기값 1200)이 문서 특성에 민감하게 반응하여, Figure가 102개 포함된 문서에서도 Vision 처리가 4페이지에만 적용되는 사례가 발생하였다. 그 결과 그림 관련 정보가 대량으로 누락될 가능성이 확인되었다.

이를 개선하기 위해 두 가지 보정을 적용하였다. 첫째, 임계값을 1200에서 3000으로 조정하여 Vision 분기의 안전 범위를 확대하였다. 둘째, Figure 캡션 직접 감지 규칙을 추가하였다. 즉, Figure N: 형식의 실제 캡션 개수가 see Figure N과 같은 본문 참조 개수를 초과하는 경우, 텍스트 분량과 관계없이 Vision 처리를 강제하도록 하였다. 이를 통해 실제 그림이 포함된 페이지와 단순히 그림을 참조하는 페이지를 구분할 수 있었다.

현재 구현(calculate_quality_score() 327~333행)에는 보정 로직이 반영되어 있으며, 문서군별 특성에 따른 임계값 조정이 여전히 중요한 운영 요소임을 확인하였다.

•4세대(최종) - 비용 최적화와 의미 단위 기반 변환

마지막 단계에서는 두 가지 구조적 개선을 결합하였다.

첫째, Vision 엔진을 Claude Haiku 4.5에서 Gemini 2.5 Flash로 변경하였다. 이를 통해 페이지당 처리 비용을 약 $0.0067에서 $0.0004 수준으로 낮추어 약 94 %의 비용 절감을 달성하였으며, 병렬 워커 구조를 적용하여 처리 속도도 확보하였다.

둘째, 문서 분할 기준을 PDF 북마크(TOC)의 L3 수준 목차 항목으로 변경하였다. 이를 통해 ‘MD 파일 하나 = 하나의 의미 단위’라는 원칙을 변환 단계에서부터 구현하였다. 이는 3장 (4)절에서 제시한 “검색 단위는 인간 저자가 수행한 의미 분할을 따른다”는 설계를 데이터 생성 단계까지 확장한 것이다. 정량 평가 결과, 섹션 경계 혼용 사례는 0건으로 확인되었다.

또한 Vision 엔진의 Gemini 전환은 단순한 변환 비용 절감에 그치지 않았다. 3장 (1)절의 비교 실험을 통해 대형 모델 기반 접근의 우위를 확인한 이후, MD → JSON 색인 생성 과정의 키워드 및 요약 추출, 챗봇의 파일 선택과 답변 생성 과정까지 Gemini 2.5 Flash 기반으로 통합하였다.

초기 설계인 1장 (2)절의 Ollama 기반 로컬 모델(Gemma, Qwen 계열)은 보조 경로로 유지되었으며, 최종 파이프라인은 문서 변환(Vision), 지식 색인(키워드·요약 생성), 질의응답(파일 선택·답변 생성)의 세 단계 모두를 동일한 추론 모델(Gemini 2.5 Flash) 기반으로 운영하는 구조로 발전하였다.

(6) 구현 : 코드 수준의 전환 내역

여기에서는 아키텍처 전환이 실제 소스 코드 수준에서 어떤 변화를 가져왔는지 구체적으로 기술한다.

전환 이전 시스템은 크게 두 개의 스크립트로 구성되어 있었다. build_index.py는 MD 파일을 헤더 기준으로 청킹하고, bge-m3 임베딩 모델을 이용하여 벡터화한 후 ChromaDB 컬렉션에 저장하는 인덱싱 스크립트였다. 또한 chat_gui.py는 사용자의 질의를 임베딩한 뒤 코사인 유사도 기반의 top-k(4~5) 청크를 검색하고, 검색 결과를 Ollama 기반의 로컬 모델(Deep Seek-R1, Gemma, Qwen2.5 계열)에 전달하는 Streamlit 챗봇이었다.

즉, 기존 데이터 흐름은 다음과 같았다.

MD → build_index.py → ChromaDB(청크 저장) → chat_gui.py → Ollama → 답변

아키텍처 전환의 첫 번째 변화는 새로운 구성요소의 추가가 아닌 기존 검색 계층의 제거였다. build_index.py와 ChromaDB 기반 벡터 인덱스는 제거되었으며, 질의 임베딩, 유사도 계산, 검색 결과 청크 조합에 해당하는 코드 경로 역시 함께 삭제되었다. 이는 3장 (3)절에서 설명한 “청크 검색의 필요성 소멸”이 구현 수준에서는 벡터 인덱싱 계층 자체의 제거로 나타난 것이다.

기존 인덱싱 계층이 제거된 자리는 목적이 다른 두 가지 구성 요소로 대체되었다.

첫째, md2json.py는 각 MD 파일을 분석하여 제목, 키워드, 요약으로 구성된 메타데이터를 생성하고 JSON 인덱스를 구축한다. 기존 벡터 인덱스와의 가장 큰 차이는 인덱스 내용이 사람이 해석 가능한 자연어 기반 정보라는 점이다. 또한 원문 데이터는 별도의 변환이나 분할 없이 그대로 보존된다. 기존 청킹 기반 파이프라인에서는 검색 효율을 위해 원문을 여러 조각으로 분해하는 과정이 필수였지만, LAR 구조에서는 원문 자산과 실행용 인덱스를 분리함으로써 원문 손실 가능성을 제거하였다.

둘째, LAR_chatbot(chat_gui.py)에서는 검색 과정이 기존 함수 기반의 벡터 검색에서 LLM 기반 파일 선택 과정으로 변경되었다. 또한 질의 처리 흐름은 IDLE → CLASSIFYING → CONFIRMING → PRO CESSING의 4단계 상태 구조로 재설계되었으며, 실제 핵심 동작은 두 번의 LLM API 호출로 구성된다.

첫 번째 호출에서는 Gemini가 JSON 인덱스에 포함된 메타데이터(제목, 키워드, 요약)만을 참조하여 사용자 질의에 적합한 문서를 추론적으로 선택한다. 이 과정이 바로 LAR에서 정의한 LLM-as-Retriever이며, 기존 임베딩 기반 검색을 LLM의 문맥 이해와 추론 기반 선택으로 대체한 부분이다.

선택 결과는 사용자에게 ‘추천 파일’과 ‘추가 선택 가능 파일’ 형태로 제시되며, 사용자는 이를 확인하거나 수정할 수 있다(CONFIRMING 단계). 이후 확정된 파일의 원문은 JSON 인덱스의 content 필드에서 호출되어 두 번째 LLM API의 컨텍스트로 직접 주입되고, 모델은 해당 전문 내용을 기반으로 최종 답변을 생성한다.

(7) 선행 연구와의 관계 및 본 보고서의 의미

본 보고서는 LAR의 방법론적 위치를 기존 선행 연구와의 관계 속에서 명확히 한다. 문서 전체를 컨텍스트에 사전 적재(preload)해 실시간 검색 과정을 우회하는 접근은 Cache-Augmented Generation(CAG)이라는 이름으로 Chan 등(2024, arXiv:2412.15605)에 의해 정식화되었으며, 이후 관련 연구로 확장되었다. 또한 문서 목록과 요약 정보를 기반으로 LLM이 대상 문서를 추론적으로 선택하는 방식은 Agent-based RAG 및 임베딩 없는 검색(embedding-free retrieval) 계열에서 연구되어 왔다. 장문 컨텍스트(Long Context, LC)와 청크 기반 RAG의 성능 비교 역시 다수의 벤치마크 연구(Li 등, 2025 외)를 통해 수행되었으며, 질의응답 과제에서는 장문 컨텍스트 모델이 청크 기반 RAG 대비 우수한 성능을 보이는 사례가 보고되고 있다.

따라서 3장 (4)절에서 제시한 LAR의 세 가지 핵심 설계 원칙인 검색 단위의 확장, 검색 주체의 전환, 증강 방식의 무손실화는 독립적으로는 기존 연구에서 다뤄진 개념이다. 특히 LAR은 CAE 기술문서 환경에 맞게 결합·적용한 도메인 특화 아키텍처로 볼 수 있다.

본 보고서의 기여는 새로운 알고리즘이나 검색 패러다임 자체를 제안하는 데 있지 않으며, 다음 세 가지 측면에서 찾을 수 있다.

첫째, 청크 기반 RAG의 한계를 FEM 기술문서의 구조적 특성과 연결하여 분석하고, 이를 실제 시스템 구축 과정에서 검증한 사례를 제시했다는 점이다. 수식 전개의 연속성, 표 구조의 의미 완결성, 키워드 간 상호참조성 그리고 저자가 구성한 목차 계층 구조 등 FEM 문서가 갖는 도메인 특성을 기반으로 청킹 접근의 한계를 인과적으로 분석하였다. 이는 일반적인 벤치마크 데이터셋 중심의 성능 비교 연구와 차별화되는 부분이다.

둘째, 동일 소스를 대상으로 한 대조 실험을 통해 데이터 품질이라는 변인을 통제한 상태에서 검색 단위와 모델 규모가 답변 품질에 미치는 영향을 분석했다는 점이다. 3장 (1)절의 비교 실험은 동일한 지식 자산을 대상으로 시스템 구조 차이가 결과 품질에 미치는 영향을 확인했다.

셋째, 기업 내부 기술 자료를 대상으로 하는 보안 요구사항과 제한된 하드웨어 환경을 동시에 고려한 실용적 설계 패턴을 제시했다는 점이다. 지식 자산은 로컬 환경에 유지하면서도 장문 컨텍스트 모델을 활용하는 구조를 통해, 고성능 GPU나 별도 인프라 없이 운용 가능한 LAR 구현 방식을 제안하였다.

요약하면, LAR은 새로운 검색 패러다임이라기보다 CAG와 Agent-based RAG의 개념을 CAE 기술문서라는 특정 도메인에 적용한 사례 연구이다. 본고의 2장에서는 기존 접근 방식의 실패 원인을 단계별로 분석하고, 이를 해결하기 위해 도입한 방법론과 그 효과를 실제 데이터 기반의 검증 결과와 함께 상세히 제시하였다.

4. 결론 - 요약, 교훈 그리고 향후 과제

본고는 CAE 기술문서 질의응답 시스템 구축 과정에서 청크 기반 RAG가 데이터 변환·청킹·임베딩 검색의 각 단계에서 직면한 한계를 분석하고, 그 원인이 개별 구현 기법의 부족이 아니라 “문서를 독립적인 조각의 집합으로 취급할 수 있다”는 청킹의 기본 전제와 FEM 문서 구조 간의 본질적 불일치에 있음을 밝힌다.

동일 소스를 대상으로 한 비교 실험을 통해, 검색 단위(청크 vs 전문)와 모델 규모의 조합이 답변 품질을 결정하는 주요 요인임을 확인하였다. 이를 바탕으로 제안한 LAR 아키텍처는 자산(MD)과 실행 인덱스(JSON)를 분리하고, LLM이 질의에 적합한 파일을 선택한 후 해당 전문을 직접 주입하는 방식으로 설계되었다. 이 접근은 기존 청킹 기반 RAG가 도달하지 못했던 수준의 답변 품질을 실제 업무 환경에서 달성하였다.

또한 이러한 구조 전환은 임베딩 모델, 벡터 데이터베이스, 로컬 추론 모델 등 GPU 자원을 요구하는 주요 구성요소를 제거함으로써, 고성능 하드웨어나 별도의 인프라 없이 일반적인 업무용 노트북 환경에서도 개인 엔지니어가 구축·운용할 수 있는 시스템이라는 초기 목표를 품질 저하 없이 달성하였다.

일반적으로 문서가 체계적인 계층 구조를 갖추고 개별 단위의 의미적 완결성이 높은 도메인에서는 정보 간 상호참조성이 높아 조각 단위 검색이 문맥 손실을 유발하는 경우가 많다. 이러한 조건에서는 청크 기반 RAG보다 전문 주입(full-document injec-tion) 계열 접근의 효과가 더욱 커질 수 있다. CAE 기술문서는 이러한 특성을 극단적으로 보여주는 대표적인 사례이다.

 

 참고 문헌 (초안 단계 주요 항목)

•Chan, B. J., Chen, C.-T., Cheng, J.-H., & Huang, H.-H. (2024). Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks. arXiv:2412.15605

•Li, X., Cao, Y., Ma, Y., & Sun, A. (2025). Long Context vs. RAG for LLMs: An Evaluation and Revisits. arXiv:2501.01880

•Li et al. (2024). Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

•Li et al. (2025). LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs

•기타 관련 연구: Agent-based RAG, embedding-free retrieval(ELITE), LongRAG, OP-RAG, CAG 등

*LAR은 LLM-as-Retriever를 의미하며, 본서에서는 해당 의미로 한정하여 사용한다.

 

cipark@alten-korea.com