제가 AI 엔지니어로 Strokx Technologies에 합류했을 때, 저의 첫 번째 실제 프로젝트는 현재 많은 팀이 다루고 있는 과제였습니다. 바로 어떻게 하면 직원들이 방대하고 무질서한 내부 문서 더미를 대상으로 자연어 질문을 던지게 하고, 단순히 그럴듯하게 들리는 답변이 아닌 실제로 정확한 답변을 얻게 할 것인가 하는 문제였습니다.

이것이 바로 검색 증강 생성 (Retrieval-Augmented Generation, RAG)의 핵심 과제이며, 제가 4개월 동안 구축하는 데 매진했던 내용입니다. 바로 내부 문서를 흡수하고 이를 바탕으로 질문에 답하는 엔터프라이즈급 지식 어시스턴트입니다. 저는 환각 (hallucination) — RAG 시스템이 프로덕션 환경에서 사용자 신뢰를 얻지 못하는 가장 큰 이유 — 을 줄이기 위한 구체적인 엔지니어링 선택에 집중했습니다.

이 시스템이 어떻게 구축되었는지, 그 과정에서 무엇이 고장 났는지, 그리고 다음에 다시 한다면 무엇을 다르게 할 것인지에 대해 설명하겠습니다.

왜 단순한 RAG로는 충분하지 않은가

기본적인 RAG 레시피는 이제 잘 알려져 있습니다. 문서를 임베딩 (embed) 하고, 벡터 (vector)를 저장하며, 주어진 쿼리에 대해 가장 유사한 상위 k개의 청크 (chunk)를 검색하고, 이를 프롬프트 (prompt)에 집어넣은 뒤, LLM이 답변을 생성하게 하는 방식입니다.

이 방식은 작동합니다 — 작동하지 않기 전까지는 말이죠. 실제로 단순한 RAG는 몇 가지 예측 가능한 방식으로 실패합니다:

• 잘못된 청킹 (chunking)은 테이블이나 절차를 생각의 중간 단계에서 분리해 버리며, 이로 인해 검색 결과가 기술적으로는 관련이 있지만 의미론적으로는 불완전한 파편을 반환하게 됩니다.
• 과도한 검색 (Over-retrieval)은 느슨하게 관련된 너무 많은 컨텍스트 (context)를 프롬프트에 쏟아부어, 모델이 서로 다른 문서의 사실들을 섞기 시작하게 만듭니다.
• 침묵의 실패 (Silent failure) — 지식 베이스에 질문에 답할 수 있는 내용이 실제로 없을 때, 단순한 시스템은 여전히 자신 있게 무언가를 생성해 냅니다. 파이프라인 내에서 검색된 컨텍스트가 실제로 답변을 뒷받침하는지 확인하는 과정이 없기 때문입니다.

마지막 문제가 제가 가장 많은 시간을 할애했던 문제였습니다.

인제스션 (ingestion) 파이프라인

첫 번째 실질적인 설계 결정은 청킹 (chunking) 전략이었습니다. 고정 길이 청킹 (예: 매 500 토큰마다)은 간단하지만 문서 구조를 무시합니다. 즉, 번호가 매겨진 절차를 중간에 잘라버릴 수도 있습니다. 대신, 저는 의미론적 경계 (semantic boundaries)를 존중하는 청킹 단계를 구축했습니다. 주로 제목과 단락 구조를 기준으로 분할하며, [~400–600 토큰]의 목표 크기를 설정하고 인접한 청크 사이에 중첩 (overlap)을 두어 경계 부분에서 문맥이 손실되지 않도록 했습니다.

각 청크는 [sentence-transformers / OpenAI embeddings — 실제 모델로 교체]를 사용하여 임베딩 (embedding)되었으며, 소스 문서, 섹션 제목, 인제스션 (ingestion) 타임스탬프와 같은 메타데이터 (metadata)와 함께 [vector database — 예: ChromaDB / FAISS / Pinecone]에 저장되었습니다. 이 메타데이터는 제가 처음에 예상했던 것보다 더 중요하게 작용했습니다. 시스템이 답변의 출처를 인용할 수 있게 해주었는데, 이는 초기 사용자들이 테스트를 시작한 후 가장 많이 요청된 기능 중 하나가 되었습니다.

환각 (hallucination) 감소

이것은 마지막에 덧붙인 부차적인 문제가 아니라, 핵심적인 엔지니어링 문제였습니다. 다음과 같은 몇 가지 사항이 유의미한 도움이 되었습니다:

생성 전 그라운딩 (grounding) 확인. LLM이 최종 답변을 생성하기 전에, 파이프라인은 검색된 청크가 쿼리 (query)와 실제로 관련된 내용을 포함하고 있는지 확인합니다. 단순히 임베딩 유사도 (embedding-similarity) 측면에서 관련이 있는 것이 아니라, 실질적으로 관련이 있어야 합니다. 만약 검색 신뢰도가 임계값 (threshold) 미만으로 떨어지면, 시스템은 모델이 유창하게 들리는 추측으로 공백을 채우도록 내버려 두는 대신, "이 질문에 대한 충분한 정보가 없습니다"라는 명시적인 응답을 반환합니다.

제약된 프롬프팅 (Constrained prompting). 생성 프롬프트는 모델에게 오직 제공된 문맥 (context) 내에서만 답변하고, 문맥이 불충분할 경우 이를 말하도록 명시적으로 지시합니다. 작은 부분이지만, 테스트 과정에서 자신감 있게 틀린 답변을 내놓는 경우를 측정 가능한 수준으로 줄여주었습니다.

강제 기능 (forcing function)으로서의 출처 인용 (Source attribution). 모든 답변에 해당 답변이 추출된 소스 청크 (source chunk)를 인용하도록 요구하는 것은 그 자체로 훌륭한 환각 (hallucination) 방지책임이 드러났습니다. 모델이 사실을 조작하면서 동시에 그에 그럴듯해 보이는 인용구까지 동시에 조작하는 것은 더 어렵기 때문입니다.

이 방법들 중 그 어떤 것도 환각을 완전히 제거하지는 못합니다. 적어도 아직까지는 그 어떤 것도 불가능합니다. 하지만 이 방법들을 함께 사용함으로써 "가끔 자신 있게 틀리는" 상태를 "자신의 불확실성에 대해 대개 솔직한" 상태로 바꾸어 놓았습니다. 이것이 바로 사람들이 업무에서 신뢰해야 하는 도구에 있어 실제로 중요한 기준입니다.

다르게 했을 점

만약 제가 이 작업을 다시 시작한다면, 검색 평가 (retrieval evaluation)에 더 일찍 투자했을 것입니다. 즉, 정답이 확인된 소스 청크가 포함된 작은 라벨링된 질문 세트 (labeled set of questions)를 구축하고, 생성 (generation) 측면을 다루기 전에 검색 정밀도 (retrieval precision)와 재현율 (recall)을 측정했을 것입니다. 저는 주로 엔드 투 엔드 (end-to-end) 답변 품질을 반복 개선하며 이 시스템을 구축했는데, 이로 인해 나쁜 답변이 검색 문제인지 아니면 생성 문제인지 구분하기 어려웠습니다. 검색 전용 평가 세트 (retrieval-specific eval set)가 있었다면 디버깅 시간을 크게 단축했을 것입니다.

또한, 텍스트가 아닌 소스를 처리할 수 있도록 인제스션 파이프라인 (ingestion pipeline)을 확장하고 싶습니다. 많은 내부 지식은 깔끔한 산문이 아니라 슬라이드 데크 (slide decks)나 스프레드시트 (spreadsheets)에 존재하며, 현재의 파이프라인은 상당히 잘 구조화된 텍스트 문서를 가정하고 있기 때문입니다.

향후 방향

RAG는 주말 동안 만든 데모와 프로덕션에서 신뢰할 수 있는 시스템 사이의 격차가 위에서 다룬 세부 사항들—청킹 (chunking) 규율, 검색 평가, 그리고 "모르겠습니다"를 유효하고 중요한 출력으로 취급하는 것—에 거의 전적으로 달려 있는 분야 중 하나입니다. 이것이 제가 이 프로젝트에서 가장 흥미롭다고 느낀 부분이며, 제가 계속해서 구축해 나가고 싶은 방향입니다.

이 프로젝트의 코드는 GitHub에 있습니다: Enterprise-GenAI-Knowledge-Assistant

유사한 작업을 하고 계시거나 RAG 평가 전략에 대한 의견이 있으시다면 듣고 싶습니다. LinkedIn에서 저를 찾으시거나 kirankrishna2024.github.io에서 저의 더 많은 작업물을 확인해 주세요.