Pragmatic Agent — Custom Inference & Agentic RAG SaaS

🎯 프로젝트 개요

Pragmatic Agent는 단순한 API 호출형 RAG의 한계를 극복하기 위해, LLM 추론 엔진과 Agentic 워크플로우를 독자적으로 설계한 SaaS형 AI 서비스 개발 프로젝트입니다.

LangChain, LlamaIndex 등 기성 프레임워크의 높은 추상화로 인한 제약을 탈피하여, KV-Cache 관리, 디코딩 정책 제어, 다중 경로 추론(ToT/Reflexion) 모듈을 직접 내재화함으로써 응답 품질과 지연 시간(Latency)을 최적화하는 엔지니어링 제어권을 100% 확보했습니다.

제한된 리소스 환경에서 최적의 추론 효율을 달성하기 위해 마이크로서비스 아키텍처(MSA) 를 채택하였으며, 현재 Hugging Face Spaces(PaaS) 를 통해 사용자 세션 관리 및 대화기록 저장 기능이 포함된 MVP 서비스가 성공적으로 배포된 상태입니다.

🛠 Tech Stack

Category	Tools & Technologies
Backend	Language: Python, Framework: Gradio
AI/ML	Framework: PyTorch, Numpy, Transformers Main Model: GPT-OSS 20B (Reasoning Core) Sub Models: BGE-M3 (Text Embedder), BGE-Reranker-v2 Custom Inference Engine: PyTorch + Transformers
Search & Storage	Search & Retrieval: Retrieval: Hybrid (Manual BM25 + Faiss Vector) Storage: SQLite (Metadata & Sessions).
Infrastructure	Deployment: Docker, Hugging Face Spaces (PaaS Hosting) Security: Hugging Face OAuth 2.0.

✨ 주요 특징

자체 구축(Custom) LLM 추론 엔진: KV-Cache 제어(Eviction/Fork) 및 디코딩 최적화를 통한 지연 시간 최소화
고급 Agentic 오케스트레이션: Tree of Thoughts(ToT), Reflexion, Self-Consistency 알고리즘을 프롬프트 레벨이 아닌 추론 파이프라인 코어 로직으로 구현
지능형 Planning & Reranking: 에이전트가 직접 외부 API(Google Search) 호출을 결정하고, Cross-encoder로 문맥을 정제하여 노이즈 제거
마이크로서비스 아키텍처(MSA): 에이전트 추론 애플리케이션(app)과 검색/DB 엔진(rag)의 역할을 분리하여 독립적 스케일링 가능
SaaS형 UI/UX: HF OAuth 로그인, 영구 대화 세션 복원 및 상태(State) 관리

🏗️ 핵심 아키텍처 (MSA 구조)

시스템은 '추론 및 자율 행동'을 담당하는 App 서버와 '검색 및 정제'를 담당하는 RAG 서버로 분리되어 병목 현상을 방지합니다.

graph TD
    subgraph Client_Layer [Client Interface]
        UI[Gradio Web UI]
        OAuth[HF OAuth 2.0]
    end

    subgraph App_Service [App Container: Agent & Reasoning]
        direction TB
        Orchestrator{Agentic Orchestrator}
        
        subgraph Strategies [Reasoning Strategies]
            ToT[Tree of Thoughts]
            Reflexion[Self-Reflexion]
            CoT[Chain of Thought]
        end

        subgraph Engine [Custom Inference Engine]
            Runtime[LLM Runtime]
            KV[KV-Cache Manager]
            Dec[Decoding Controller]
        end
        
        LLM[(GPT-OSS 20B)]
    end

    subgraph RAG_Service [RAG Container: Retrieval & Search]
        direction TB
        SearchRouter[Search Router]
        
        subgraph Retrieval [Hybrid Retrieval]
            BM25[Custom BM25]
            Faiss[Faiss Vector Index]
        end
        
        Reranker[BGE-Reranker-v2]
        Corpus[(Wiki/Doc DB)]
    end

    %% Flow Connections
    UI <--> OAuth
    UI <--> Orchestrator
    
    Orchestrator --> Strategies
    Strategies --> Engine
    Engine <--> LLM
    Engine <--> KV
    
    Orchestrator <== "gRPC / REST API" ==> SearchRouter
    SearchRouter --> Retrieval
    Retrieval --> Corpus
    Retrieval --> Reranker
    Reranker --> SearchRouter
    
    %% External Tools
    SearchRouter -.-> Web[External Web Search]

    %% Styling
    style App_Service fill:#f9f,stroke:#333,stroke-width:2px
    style RAG_Service fill:#bbf,stroke:#333,stroke-width:2px
    style Engine fill:#b9f,stroke:#f66,stroke-dasharray: 5 5

App Module: 사용자 의도 파악(Planning) → 추론 전략 할당(ToT, Reflexion) → 로우레벨 텍스트 생성 제어
RAG Module: 하이브리드 검색 수행 → Reranker 기반 노이즈 필터링 → Context 압축 및 반환

🔑 핵심 기능

⚙️ Low-level 추론 제어 (Custom Inference)

Memory & Cache:
- 상태가 없는(Stateless) LLM의 한계를 극복하기 위해 자체 KV Cache Manager 구현.
- 복잡한 추론 과정(다중 턴)에서 발생하는 OOM(Out of Memory) 방지를 위해 Cache Eviction(폐기) 및 Fork(복제) 정책을 직접 설계하여 메모리 효율성 극대화.
Decoding & Controller:
- CFG(Classifier-Free Guidance), Contrastive 디코딩 및 Speculative Decoding 구조를 적용하여 응답 생성의 다양성과 속도 제어.

🧠 Agentic Orchestrator

Workflow Router: 사용자의 입력 복잡도에 따라 Decision(판단), Multi-turn(대화), Refine(교정) 등 최적의 워크플로우를 동적으로 할당.
Strategies: Chain of Thought를 넘어, 답변의 논리적 오류를 스스로 교정하는 Reflexion(자가 검증) 및 여러 가능성을 탐색하는 Tree of Thoughts 파이프라인 내재화.

🔍 RAG Microservice

단일 파이프라인의 병목을 막기 위해 검색 모듈을 독립 서비스로 분리.
BM25 + Dense 하이브리드 검색 후 Reranker를 통한 2차 문맥 정제 수행.

🧩 기술적 과제와 해결 접근

문제 1: 기성 RAG 프레임워크의 과도한 추상화 및 최적화 한계 → 해결: LangChain 등을 배제하고, controller, decoding, orchestrator 모듈을 직접 구축하여 파이프라인 제어권 100% 확보 및 토큰 생성 속도 최적화 달성.
문제 2: 단순 Vector 검색으로 인한 낮은 문맥 적합도 → 해결: 검색된 수십 개의 문서를 Cross-encoder 기반의 Reranker 모델로 재평가하여, 토큰 예산 내에 들어갈 가장 핵심적인 문맥만 Generator에 주입.
문제 3: 긴 문맥 처리 문제 → 해결: Chunking + 임베딩 후 청크별 추론 및 결과 종합

🔗 링크 및 데모

Live MVP Demo: HF Spaces
Source Code: GitHub Repository