제가 만든 것

저는 고객 지원 워크플로우를 연습하는 친구가 정확한 답변을 지원 문서에서 더 빠르게 찾을 수 있도록 도와주기 위해 고객 지원 AI 시스템을 구축했습니다.

고객 지원 분야의 흔한 문제는 정보 자체가 존재하지만, 올바른 정보를 찾는 데 시간이 걸린다는 것입니다.

지원팀은 FAQ, 환불 정책, 계정 정책, 결제 문서 및 기타 참조 문서를 여러 파일에 분산하여 가지고 있을 수 있습니다.

이러한 문서들을 수동으로 검색하는 대신, 저는 지원 지식을 업로드하고 의미적 유사성(semantic similarity)을 사용하여 검색할 수 있는 시스템을 구축했습니다.

이 시스템은 다음 기능을 수행할 수 있습니다:

• FAQ, 지원, 정책, PDF, TXT 및 Markdown 문서를 업로드합니다
• 문서 텍스트를 추출합니다
• 겹치는 청크(overlapping chunks)로 텍스트를 정리하고 분할합니다
• 임베딩(embeddings)을 생성합니다
• ChromaDB에 임베딩을 저장합니다
• 의미적 검색(semantic search)을 수행합니다
• 관련 청크와 출처 메타데이터를 반환합니다.
• 검색된 정보의 원본 문서 및 페이지를 추적합니다.

목표는 간단합니다:

지원 담당자가 올바른 정보를 더 빠르게 찾도록 돕는 것입니다.

데모

이 프로젝트에는 지식 기반과 상호 작용할 수 있는 Streamlit 데모 인터페이스가 포함되어 있습니다.

예시 질문

시스템은 다음과 같은 질문들로 테스트할 수 있습니다:

• 고객이 환불을 요청하는 기간은 얼마나 되나요?
• 계정이 잠겼다면 어떻게 해야 하나요?
• 비밀번호 재설정 이메일은 얼마나 빨리 전송되나요?
• 어떤 결제 방법이 지원되나요?
• 30일이 지난 후에 환불을 요청할 수 있나요?

리포지토리에는 또한 API와 상호 작용하기 위한 FastAPI 백엔드와 Swagger 문서가 제공됩니다.

데모:
[https://github.com/Sinjini1803/Customer-Support-System]

코드

전체 소스 코드는 여기에서 확인할 수 있습니다:

GitHub:
[https://github.com/Sinjini1803/Customer-Support-System]

이 리포지토리에는 애플리케이션 코드, 샘플 데이터, 테스트, Docker 구성, 인제스천 파이프라인(ingestion pipeline) 및 데모 인터페이스가 포함되어 있습니다.

구축 과정 (How I Built It)

이 시스템은 검색 증강 생성(Retrieval-Augmented Generation, RAG) 스타일의 지식 파이프라인을 기반으로 구축되었으며, 현재 구현은 검색(retrieval) 단계에 중점을 두고 있습니다.

아키텍처는 다음과 같습니다:

지원 문서 (Support Documents)
↓
업로드 API (Upload API)
↓
PDF/텍스트 추출 (PDF / Text Extraction)
↓
텍스트 클리닝 (Text Cleaning)
↓
청크 분할 및 중복 처리 (Chunking + Overlap)
↓
문장 임베딩 (Sentence Embeddings)
↓
ChromaDB
↓
사용자 질의 (User Query)
↓
질의 임베딩 (Query Embedding)
↓
의미적 유사성 검색 (Semantic Similarity Search)
↓
상위-K개 관련 청크 (Top-K Relevant Chunks)
↓
출처 메타데이터 (Source Metadata)

저장소(repository)는 PyMuPDF를 사용하여 PDF/텍스트 추출을 구현하고, 중복되는 청크를 생성하며, Sentence Transformers를 사용하여 정규화된 임베딩을 생성하고, 이 벡터들을 ChromaDB에 저장합니다.

1. 문서 수집 (Document Ingestion)

지원 문서는 API를 통해 업로드할 수 있습니다.

예시:

curl -X POST [http://localhost:8000/ingest](http://localhost:8000/ingest) \ -F "file=[@data](https://dev.to/data)/sample_documents/refund_policy.pdf"

시스템은 문서 내용을 추출하고 이를 관리 가능한 청크로 분할합니다.

각 청크는 다음과 같은 메타데이터를 유지합니다:

• 문서 ID (Document ID)
• 문서 이름 (Document name)
• 문서 유형 (Document type)
• 페이지 번호 (Page number)
• 청크 번호 (Chunk number)
• 출처 파일명 (Source filename)
• 업로드 타임스탬프 (Upload timestamp)

이는 검색 결과가 원래의 문서와 페이지로 추적될 수 있음을 의미합니다.

2. 임베딩 (Embeddings)

문서 처리가 완료된 후, 텍스트 청크는 Sentence Transformer 모델을 사용하여 숫자 벡터 표현으로 변환됩니다.

이를 통해 시스템은 사용자의 질문의 의미를 저장된 지원 정보의 의미와 비교할 수 있게 되며, 단순히 정확한 키워드 일치에만 의존하지 않습니다.

3. ChromaDB

생성된 임베딩은 ChromaDB에 저장됩니다.

사용자가 질문을 하면, 이 질문 역시 임베딩으로 변환됩니다.

시스템은 이후 의미적 유사성 검색(semantic similarity search)을 수행하여 가장 관련성이 높은 청크를 검색합니다.

사용자 질문 (User Question)
↓
질의 임베딩 (Query Embedding)
↓
ChromaDB 검색 (ChromaDB Search)
↓
상위-K개 관련 청크 (Top-K Relevant Chunks)
↓
문서 + 페이지 메타데이터 (Document + Page Metadata)

현재 API는 청크 텍스트, 유사도 점수, 문서 정보, 페이지 번호, 청크 ID 및 소스 파일명을 반환합니다.

1. FastAPI 백엔드

백엔드는 FastAPI를 사용하여 구현되었습니다.

이 프로젝트는 다음 엔드포인트를 제공합니다:

• 상태 확인 (Health checking)
• 문서 수집 (Document ingestion)
• 시맨틱 검색 (Semantic search)

또한 로컬에서 실행할 때 다음을 통해 Swagger 문서를 노출합니다:

http://localhost:8000/docs

1. Streamlit 데모

Streamlit 인터페이스는 API 엔드포인트를 수동으로 호출할 필요 없이 지식 기반과 상호 작용하는 간단한 방법을 제공합니다.

이 프로젝트는 다음 명령어로 시작할 수 있습니다:

streamlit run demo/streamlit_app.py

저장소에는 Docker 및 Docker Compose 지원도 포함되어 있습니다.

오픈 혁신(Open Innovation)은 왜 중요할까요?

제가 완전히 폐쇄적인 AI API에 의존하기보다는 오픈 도구를 사용하여 얼마나 많은 AI 기반 지원 워크플로우를 구축할 수 있는지 이해하고 싶었기 때문에 이 프로젝트에 오픈 혁신이 중요했습니다.

이 프로젝트는 핵심 검색 파이프라인에 오픈 소스 구성 요소를 사용합니다:

• 임베딩을 위한 Sentence Transformers
• 벡터 저장을 위한 ChromaDB
• 백엔드를 위한 FastAPI
• 데모 인터페이스를 위한 Streamlit

이는 개발자에게 시스템의 개별 부분에 대한 더 많은 제어권을 부여합니다.

유연성 (Flexibility)

임베딩 모델은 벡터 데이터베이스 및 API 계층과 독립적으로 변경할 수 있습니다.

따라서 검색 시스템이 하나의 독점 제공업체(proprietary provider)에 묶이지 않습니다.

투명성 (Transparency)

검색 파이프라인이 개별 구성 요소로 구축되었기 때문에, 문서가 어떻게 처리되고, 임베딩되며, 저장되고, 검색되는지 이해하기 쉽습니다.

개인 정보 보호 및 제어 (Privacy and Control)

고객 지원 문서는 조직이 모든 검색에 대해 외부 서비스로 보내고 싶지 않은 정보를 포함할 수 있습니다.

로컬에서 제어 가능한 구성 요소를 사용하면 개발자가 개인 정보 보호를 고려하는 시스템을 설계할 때 더 많은 유연성을 얻습니다.

학습 (Learning)

이 프로젝트를 구축하면서 AI 애플리케이션이 단순히 텍스트를 생성하는 것 이상이라는 것을 이해하는 데 도움이 되었습니다.

유용한 시스템에는 다음이 필요합니다:

좋은 문서 처리
좋은 청킹(chunking)
의미 있는 임베딩(embeddings)
효율적인 검색(retrieval)
출처 추적(source tracking)
테스트
사용 가능한 인터페이스
작지만 중요한 디자인 선택

제가 보존하고 싶었던 한 가지는 출처 추적성(source traceability)이었습니다.

지원 담당자가 검색 결과를 얻을 때, 단순히 텍스트 조각을 반환하는 것만으로는 충분하지 않습니다.

시스템은 원본 문서와 페이지를 식별할 수 있는 메타데이터를 저장합니다.

예를 들어:

문서: refund_policy.pdf
페이지: 3
청크: 2
유사도(Similarity): 0.XX

이는 검색된 정보를 검증하기 쉽게 만듭니다.

고객 지원의 경우, 이는 매우 중요합니다. 왜냐하면 답변은 이상적으로 실제 지원 문서에 근거해야 하기 때문입니다.

제가 배운 것

이 프로젝트를 구축하면서 얻은 가장 큰 교훈은 검색 품질(retrieval quality)이 AI 애플리케이션에서 극도로 중요하다는 것입니다.

이 프로젝트에 착수하기 전에는, AI 시스템을 주로 답변을 생성하는 모델로 생각하기 쉬웠습니다.

하지만 검색 파이프라인을 구축하면서, AI 시스템에 공급되는 정보의 품질 역시 매우 중요하다는 것을 알게 되었습니다.

만약 문서가 제대로 추출되지 않거나(poorly extracted), 잘못 청킹되거나(badly chunked), 검색하기 어렵다면, 아무리 강력한 언어 모델(language model)이라도 신뢰할 수 있는 답변을 생성하는 데 어려움을 겪을 것입니다.

따라서 이 프로젝트는 RAG 시스템의 기반에 대해 이해하는 데 도움을 주었습니다:

문서 → 청크 → 임베딩 → 벡터 검색(Vector Search) → 관련 컨텍스트(Relevant Context)

현재 구현은 의도적으로 검색과 답변 생성을 분리했습니다. 저장소에는 향후 반복 작업에서 의미론적 검색(semantic search) 이후에 LLM을 추가하여 인용문이 포함된 근거 기반 지원 답변을 생성하는 방법을 문서화하고 있습니다.

제 에이전트 세션(Agent Session)

선택 사항: 이번 제출물에는 DevRelay 세션을 포함하지 않았습니다.

상(Prize) 카테고리

이번 제출물은 주로 Hacktoberfest Weekend Challenge: Build for a Friend에 관한 것입니다.

필요한 파트너 기술이 프로젝트에서 실제로 사용되는 경우에만 추가 파트너 카테고리에 참가합니다.

마지막 생각(Final Thoughts)

저는 간단한 문제로 이 프로젝트를 시작했습니다:

고객 지원 정보는 사람들이 그것을 빠르게 찾을 수 있을 때만 유용합니다.

이것은 저로 하여금 지원 문서를 의미론적 지식 기반(semantic knowledge base)으로 변환하는 검색 가능한 지식 시스템을 구축하게 했습니다.

누군가에게 고객 지원 워크플로우를 연습할 기회를 제공하기 위해 시작된 것이 문서 처리, 임베딩(embeddings), 벡터 데이터베이스(vector databases), 의미론적 검색(semantic search), API, 그리고 AI 애플리케이션 아키텍처에 대한 실질적인 탐구로 발전했습니다.

저에게 가장 중요한 교훈은 유용한 AI를 구축하는 것이 항상 가장 큰 모델을 만드는 것에 관한 것은 아니라는 것입니다.

때로는 그것이 사람의 질문과 그들이 실제로 필요로 하는 정보 사이의 더 나은 경로를 구축하는 것에 관한 것입니다.

그것이 제가 친구를 위해 만들고 싶었던 것이었습니다.

devchallenge #weekendchallenge #hf26challenge