여기 RAG(Retrieval-Augmented Generation) 세금이 온전히 드러납니다: 벡터 데이터베이스 (Vector database), 임베딩 파이프라인 (Embedding pipeline), 청킹 로직 (Chunking logic), 검색 튜닝 (Retrieval tuning), 토큰 예산 관리 (Token budget management), 그리고 컨텍스트 주입 (Context injection) — 컨텍스트 윈도우 (Context window)를 초과하지 않도록 주의하며 프롬프트에 주입해야 합니다. 대부분의 튜토리얼은 실제로 중요한 부분인 '출력'에 도달하기 전까지 200줄의 코드를 다룹니다. 이 모든 인프라는 단 하나의 질문에 답하기 위해 존재합니다: "이 입력값이 내 문서에 있는 무언가와 일치하는가?" 이것은 데이터베이스의 문제가 아닙니다. 그것은 자신의 규칙을 알지 못하는 객체의 문제입니다.

진짜 악당: 당신의 객체가 도메인 (Domain)을 모르고 있다는 점입니다. LLM (Large Language Models)은 세상에 대해 많은 것을 알고 있습니다. 하지만 그들은 당신의 가격 등급, 제외 정책, 또는 당신의 팀이 지난 분기에 작성한 준수 규칙 (Compliance rules)은 알지 못합니다. 표준 관행은 다음과 같이 말합니다: 문서에서 적절한 청크 (Chunks)를 검색하여 모델을 호출하기 전에 프롬프트에 주입하는 RAG 파이프라인을 구축하십시오. 이것은 작동합니다. 하지만 이는 근거 있는 동작 (Grounded behavior)이 필요한 모든 모델에 대해, 10줄짜리 기능을 200줄짜리 인프라 프로젝트로 만들어 버립니다. 문제는 검색 (Retrieval)이 아닙니다. 문제는 당신의 도메인 객체가 "내가 생성될 때, 이 문서를 참조하라"라고 말할 방법이 없다는 것입니다.

exomodel은 이를 단 하나의 메서드 오버라이드 (Method override)로 만듭니다.

객체에 문서 부착하기
당신은 제안서 생성기를 만들고 있습니다. 당신의 비즈니스 규칙은 마크다운 (Markdown) 파일에 저장되어 있습니다:

제안 규칙

• 최소 프로젝트 예산은 $10,000입니다.
• 모든 제안서에는 가격 책정에 10%의 안전 마진이 포함되어야 합니다.
• 우리는 담배 또는 도박 산업의 기업과는 협력하지 않습니다.
• 일정 추정치는 2주의 QA 버퍼를 고려해야 합니다.

이것이 당신의 객체가 알아야 할 문서입니다. 객체가 이를 학습하는 방법은 다음과 같습니다:

from exomodel import ExoModel

class Proposal ( ExoModel ):
    client : str = ""
    project_title : str = ""
    budget : float = 0.0
    timeline_weeks : int = 0
    summary : str = ""

    @classmethod
    def get_rag_sources ( cls ):
        return [ " proposal_rules.md " ]

이것이 통합의 전부입니다. 파이프라인도, 데이터베이스도, 청킹 코드도 필요 없습니다.

p = Proposal . create ( " Draft a proposal for Acme Corp — cloud migration project, 8 weeks " )
print ( p .

budget ) # 45000.0 (10%의 안전 마진 포함)
print ( p . timeline_weeks ) # 10 (8주 + 2주의 QA 버퍼)
print ( p . summary ) # Acme Corp를 위한 클라우드 마이그레이션 프로젝트...

객체가 당신의 규칙을 적용했습니다. 당신은 단 한 줄의 프롬프트 엔지니어링 (Prompt Engineering)도 작성하지 않았습니다.

실제로 어떤 일이 일어나고 있는 걸까요?

get_rag_sources()가 정의되면, exomodel은 외부 의존성 없이 호출 시점에 내부적으로 전체 RAG 스택을 실행합니다:

1. 나열된 각 파일을 읽습니다.
2. 콘텐츠를 중첩되는 세그먼트 (Segments)로 청킹 (Chunking)합니다.
3. 청크를 인메모리 벡터 저장소 (In-memory vector store)에 임베딩 (Embedding)합니다.
4. 입력값과 가장 관련성이 높은 섹션을 검색 (Retrieval)합니다.
5. 당신의 스키마 (Schema)와 함께 프롬프트에 주입 (Inject)합니다.

외부 데이터베이스는 없습니다. 구성해야 할 임베딩 API도 없습니다. 관리해야 할 영구 상태 (Persistent state)도 없습니다. 인덱스 (Index)는 요청이 지속되는 동안 메모리에 존재합니다. 인프라가 사라진 것이 아니라, 있어야 할 곳인 객체 내부로 이동한 것입니다.

이제 객체는 자신이 무엇을 해서는 안 되는지 알고 있습니다.

RAG에 기반한 동작 (RAG-grounded behavior)은 단순히 필드를 올바르게 채우는 것만이 아닙니다. 그것은 제약 사항을 강제합니다:

p = Proposal . create ( " Draft a 5k proposal for BetMax Casino " )
print ( p . run_analysis ()) 
# → 이 제안서는 회사 정책을 위반합니다:
# 예산이 최소 기준인 $10,000 미만이며, 고객이
# 도박 산업에서 운영되고 있습니다.

이 규칙은 모델의 학습 데이터에서 온 것도 아니고, 당신이 작성한 프롬프트에서 온 것도 아니며, 당신이 직접 코딩한 검증기 (Validator)에서 온 것도 아닙니다. proposal_rules.md에서 왔습니다. 이것이 바로 근거가 있는 동작 (Grounded behavior)의 모습입니다: 소스로 추적 가능하며, 객체 수준에서 강제됩니다.

다중 소스

@classmethod
def get_rag_sources ( cls ):
    return [
        " proposal_rules.md ",
        " pricing_tiers.md ",
        " client_blacklist.md ",
    ]

exomodel은 이 모든 것을 함께 인덱싱하고 결합된 코퍼스 (Corpus) 전체에서 검색합니다. 문서를 추가하면 객체가 이를 학습합니다. 문서를 제거하면 객체가 이를 잊습니다. 다시 구축할 파이프라인도 필요 없습니다.

이 방식이 전용 벡터 데이터베이스 (Vector database)보다 우월할 때는 언제일까요? 당신의 유스케이스가 문서에 기반한 객체 동작 (Document-grounded object behavior) — 즉, 파일에 정의된 규칙에 따라 행동해야 하는 객체인 경우라면 언제나 그렇습니다.

수천 개의 문서가 있거나, 영구적인 인덱스 (persistent indices)가 필요하거나, 대규모의 교차 세션 검색 (cross-session retrieval)이 필요한 경우에는 전용 벡터 데이터베이스 (vector database)가 더 효과적입니다. 그런 경우에는 적절한 도구를 사용하십시오. 하지만 단 하나의 객체가 정책 문서 (policy document)를 준수하게 만들 목적으로 벡터 파이프라인 (vector pipeline)을 구축한 적이 있다면, 그것은 통합 비용 (integration tax)이었습니다. 이제 더 이상 그 비용을 지불할 필요가 없습니다. Docs: https://exomodel.ai GitHub: https://github.com/exomodel-ai/exomodel Install: pip install "exomodel[google]" 현재 여러분의 객체들은 어떤 규칙을 인지하지 못하고 있습니까? 그리고 그 대가로 얼마나 많은 인프라 라인을 소모하셨습니까?