SymbolicAI: LLM에 대한 신경-기호적 관점

 (github.com/ExtensityAI)
2P by GN⁺ | ★ favorite | 댓글 1개
  • SymbolicAI는 고전적 Python 프로그래밍과 LLM의 미분 가능하고 프로그래밍 가능한 성격을 결합하는 신경-기호 프레임워크로, Python 안에서 자연스럽게 쓰는 것을 목표로 함
  • 핵심 개념은 Symbol 객체 기반의 프리미티브와 LLM 결과를 검증·수정하는 계약(contracts) 이며, 기본 동작은 안전성과 속도를 위해 구문적 모드로 시작함
  • Symbol은 구문적 모드에서는 일반 Python 값처럼 동작하고, 의미적 모드에서는 문맥과 의미를 다루며 semantic=True, .sem, .map() 같은 의미 함수 호출로 전환 가능함
  • 계약 시스템은 Design by Contract 원칙을 LLM 워크플로에 적용해 입력 검증, 상태 변경, LLM 생성, 출력 검증, 실패 시 대체 응답까지 하나의 데코레이터 기반 흐름으로 다룸
  • 설치는 pip install symbolicai로 시작하며, 실제 사용에는 symconfig와 symai.config.json 설정이 필요하고, 신경-기호 엔진은 symai 패키지 사용에 필수임

SymbolicAI가 지향하는 모델

  • SymbolicAI는 신경-기호(neuro-symbolic) 프레임워크로, 일반 Python 코드와 LLM 기반 의미 처리를 함께 다룸
  • 모듈형 설계를 통해 필요에 맞게 확장·커스터마이즈할 수 있음
  • 자체 엔진 작성, 로컬 엔진 호스팅, 웹 검색, 이미지 생성 같은 도구 연동을 지원함
  • 프로젝트 이름은 Allen Newell과 Herbert Simon의 기초 작업에 대한 크레딧을 의도함

Symbol 프리미티브

  • SymbolicAI의 중심에는 Symbol 객체가 있으며, 작은 조합 가능한 연산을 Python 네이티브 문법처럼 사용할 수 있음
  • Symbol은 두 가지 동작 방식을 가짐
    • Syntactic: 전달한 문자열, 리스트, 정수 같은 일반 Python 값처럼 동작함
    • Semantic: 신경-기호 엔진과 연결되어 의미와 문맥을 다룸
  • 기본값은 구문적 모드임
    • ==, ~, & 같은 Python 연산자가 symai에서 오버로드되어 있음
    • 모든 비교나 비트시프트에서 곧바로 엔진을 호출하면 느려지고 예상치 못한 부작용이 생길 수 있음
    • 필요한 지점에서만 의미적 동작을 켜는 방식으로 안전성과 속도를 유지함

의미적 모드로 전환하는 방법

  • 생성 시점에 semantic=True를 지정하면 처음부터 의미적 Symbol로 동작함
    • 예시에서 Symbol("Cats are adorable", semantic=True)는 "feline" in S를 True로 처리함
  • 필요할 때 .sem 프로젝션을 사용해 의미적 동작으로 전환할 수 있으며, .syn으로 다시 구문적 동작으로 돌아갈 수 있음
    • 같은 "Cats are adorable" 값도 S.sem에서는 "feline" in S.sem이 True이고, 기본 S에서는 False임
  • .map() 같은 점 표기법 연산이나 다른 의미 함수 호출은 자동으로 Symbol을 의미적 모드로 전환함
    • 예시에서 과일 목록에 convert all fruits to vegetables를 적용하면 과일만 채소로 바꾸고 cat, dog는 유지함
  • .sem과 .syn 프로젝션은 같은 기본 객체에 다른 동작 계층을 씌우는 방식이어서, 하나의 Symbol 위에서 구문적·의미적 연산을 이어 붙일 수 있음

제공되는 연산 예시

  • SymbolicAI는 다양한 프리미티브를 지원하며, 문서는 primitives에 있음
  • ==는 구문적 모드에서는 리터럴 일치를 검사하고, 의미적 모드에서는 "Hi"와 "Hello" 같은 퍼지·개념적 동등성을 다룸
  • +는 구문적 모드에서는 숫자·문자열·리스트 덧셈이고, 의미적 모드에서는 의미 있는 조합, 혼합, 개념 병합을 수행함
  • &는 구문적 모드에서는 비트·논리 AND이고, 의미적 모드에서는 논리 결합, 추론, 문맥 병합을 다룸
  • 의미적 전용 기능에는 .choice(cases, default), .foreach(condition, apply), .cluster(**clustering_kwargs?), .similarity(other, metric?, normalize?) 등이 있음
    • .cluster()는 데이터를 의미적으로 그룹화하며 sklearn의 DBSCAN을 사용함
    • .similarity()는 임베딩 간 유사도를 계산함

계약으로 LLM 출력을 다루는 방식

  • SymbolicAI는 LLM이 환각할 수 있지만 코드는 그럴 수 없다는 문제의식에서 Design by Contract 원칙을 LLM 세계에 적용함
  • 계약은 사후 테스트만 의존하지 않고, 데이터 모델과 검증 제약을 데코레이터에 묶어 설계 단계에서 올바름을 다룸
  • 예시 코드의 계약 데코레이터는 다음 옵션을 사용함
    • pre_remedy=True: 잘못된 입력을 자동 수정 시도함
    • post_remedy=True: 잘못된 LLM 출력을 자동 수정 시도함
    • accumulate_errors=True: 재시도마다 오류 이력을 전달함
    • verbose=True: 터미널에 진행 상황을 표시함
    • remedy_retry_params: tries=3, delay=0.4, max_delay=4.0, jitter=0.15, backoff=1.8, graceful=False를 사용함
  • 계약이 적용된 Expression 클래스의 고수준 흐름은 다음과 같음
    • prompt: LLM이 해야 할 일을 정의하는 정적 설명이며 필수임
    • pre: 입력을 검사하며 선택 사항임
    • act: 상태를 변경하며 선택 사항임
    • LLM: SymbolicAI 엔진이 기대 답변을 생성함
    • post: 답변이 의미 규칙을 만족하는지 확인하며 선택 사항임
    • forward: 필수이며, 계약 성공 시 타입 검증된 LLM 객체를 반환하고 실패 시 graceful fallback 답변을 반환함
  • 계약 문서는 DeepWiki의 contract validation system과 features/contracts에 있음

설치와 선택 기능

  • 기본 설치는 pip로 수행함
pip install symbolicai
  • 저장소를 클론하고 uv >= 0.9.17로 Python 가상환경을 구성할 수도 있음
git clone git@github.com:ExtensityAI/symbolicai.git
cd symbolicai
uv sync --python x.xx
source ./.venv/bin/activate
  • SymbolicAI는 텍스트, 음성, 이미지를 처리하기 위해 여러 엔진을 사용하며, 웹 정보 검색을 위한 검색 엔진 접근도 포함함
  • 선택 의존성은 기능별 extra로 설치할 수 있음
    • bitsandbytes, hf, lean, llama_cpp, ocr, qdrant, scrape, search, serpapi, services, solver, whisper, wolframalpha
  • 모든 선택 의존성은 한 번에 설치 가능함
pip install "symbolicai[all]"
  • uv sync --frozen은 제공된 lock 파일에 고정된 의존성을 설치함
  • 일부 선택 의존성은 추가 설치 단계가 필요할 수 있고, 일부는 현재 실험적으로만 지원되어 예상대로 동작하지 않을 수 있음

설정 관리와 필수 엔진

  • SymbolicAI는 우선순위 기반 설정 관리 시스템을 사용함
  • 설정은 세 위치에서 우선순위 순서로 로드됨
    • 현재 작업 디렉터리의 디버그 모드: 가장 높은 우선순위이며 symai.config.json에만 적용됨
    • Python 환경의 환경별 설정: {python_env}/.symai/에 위치하며 프로젝트별 설정에 적합함
    • 홈 디렉터리의 전역 설정: ~/.symai/에 위치하며 기본 fallback 역할을 함
  • 관리 대상 설정 파일은 세 가지임
    • symai.config.json: SymbolicAI 메인 설정
    • symsh.config.json: 셸 설정
    • symserver.config.json: 서버 설정
  • symconfig는 설정 위치, 활성 설정 경로, 민감 정보가 잘린 현재 설정을 보여주며, 초기 패키지 캐싱과 설정 파일 초기화를 시작함
  • symai 패키지를 사용하려면 신경-기호 엔진이 필수임
  • 프로젝트 경로의 symai.config.json에 엔진 속성을 지정하면 환경 변수를 대체함
    • 예시 설정에는 NEUROSYMBOLIC_ENGINE_MODEL 값으로 claude-sonnet-4-6, 임베딩 모델로 text-embedding-3-small, TTS 모델로 tts-1, OCR 모델로 mistral-ocr-latest, 인덱싱 엔진으로 qdrant 등이 포함됨
  • 기본적으로 사용자 경고가 켜져 있으며, 환경 변수 SYMAI_WARNINGS=0으로 비활성화할 수 있음

테스트, 문서, 라이선스

  • 테스트 실행 예시는 다음과 같음
pytest tests
pytest -m mandatory
pytest --cov=symbolicai tests
  • 테스트 전에는 설정이 올바르게 구성되어 있어야 함
  • 다음 단계로 SymbolicAI DeepWiki 페이지, 논문, 비디오 튜토리얼을 참고할 수 있음
  • 인용 정보는 Symbolicai: A framework for logic-based approaches combining generative models and solvers라는 2024년 arXiv preprint를 가리킴
  • 프로젝트 라이선스는 BSD-3-Clause License임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이런 부두술 같은 기능이 제일 흥미로움
    예를 들어 의미 기반 map으로 ['apple', 'banana', 'cherry', 'cat', 'dog']에 “과일을 전부 채소로 바꿔”를 적용하면 ['carrot', 'broccoli', 'spinach', 'cat', 'dog']처럼 나오고, equals()는 context='greeting context'나 context='politeness level'처럼 문맥에 따라 비교 결과가 달라짐
    비트 연산자도 의미적 논리 결합처럼 쓰여서 horn_rule & observation이 추론으로 이어지는 식이라 interpret()가 강력해 보임
    만든 계기, 실제 적용처, 지금까지 가장 마음에 든 사용 사례가 궁금함

    • Lotus도 흥미로울 수 있음: https://github.com/lotus-data/lotus
      핵심 관계형 연산자들을 Python 데이터프레임 라이브러리 확장으로 의미 기반 버전으로 만든 것이고, 각 호출이 나중에 학습 기반 접근 같은 더 복잡한 작업을 위한 “모델” 지점이 됨
      Snowflake 같은 클라우드 SQL 쪽도 이 방향으로 가는 것처럼 보이고, louie.ai에서도 AI 노트북/대시보드/API(MCP 등)로 Splunk, Databricks, 그래프 DB 같은 데이터에 말을 걸면 문맥에 맞춰 기호적+의미적 연산자를 알아내는 비슷한 방식을 썼는데 실전에서 꽤 유용했음
      주된 80% 사용 사례는 “Splunk 인덱스 xyz에서 모든 알림을 가져와 수상한 항목을 표시하는 열과 이유를 설명하는 열을 추가해” 같은 의미 기반 map으로 보강된 데이터프레임을 만들고, 이어서 “찾은 것을 요약해” 같은 의미 기반 reduce로 자연어 설명을 얻는 흐름임
    • 왜 apple을 채소화하면 carrot이 되는지 궁금함
    • 아주 긴 답이 될 것 같음
      2022년 말 프로젝트를 시작했을 때와 크게 달라진 건 많지 않고, 모델이 더 좋아졌을 뿐 GPT-3 시절부터 원시 연산 상당수는 이미 있었음
      최근에 더 중요한 건 DbC 기여인데, 계약을 연결할 수 있고 가드레일이 잘 전파돼서 에이전트 관련으로 던진 거의 모든 문제를 해결해줬다는 점이 독특함
      Perplexity는 OpenAI 웹 검색 때문에 쓸모가 줄었고, OpenAI 웹 검색도 직접 커스터마이즈한 것만큼 충분하지 않아서 자체 심층 리서치 에이전트를 만들었음: https://x.com/futurisold/status/1931751644233945216
      회사에서도 계약 3개를 연결해 종단 간 문서 생성을 만들었고, 출력 예시는 여기 있음: https://drive.google.com/file/d/1Va7ALq_N-fTYeumKhH4jSxsTrWD...
      입력은 주요 AI 제공자들의 시스템 프롬프트를 비교 분석해 XML/Markdown/JSON 같은 형식, 아첨성·조작성 지시, 도구 사용 제약, 윤리적 가드레일, 정렬 설계 차이를 찾아 기술 보고서로 종합하라는 요청이었고, 생성된 지시는 OpenAI, Google, Anthropic, xAI 등의 시스템 프롬프트 구조와 언어적 프레임워크, 운영 제약을 비교하는 구체적 질문들로 확장됐음
      계약은 3월 글에서 소개됐고 이후 많이 발전했지만 기반과 동기는 그대로임: https://futurisold.github.io/2025-03-01-dbc/

  • 논문과 예제 노트북을 같이 링크하는 게 이해에 도움이 될 듯함
    https://github.com/ExtensityAI/symbolicai/blob/main/examples...
    https://arxiv.org/pdf/2402.00854

  • 멋짐
    ==, + 같은 연산자를 구문이 아니라 의미 기반 연산자로 쓸 수 있으면 새로운 아이디어의 비료가 될 것 같고, 단어 임베딩이 처음 나왔을 때 “King - Man + Woman = Queen” 같은 느슨한 개념 대수가 생겼던 느낌과 비슷함
    다만 여기서의 신경망+기호 통합은 대부분의 시스템처럼 꽤 얕고 방화벽이 있는 구조로 보이며, 분류상 Type 3 / Neuro;Symbolic에 가까움: https://harshakokel.com/posts/neurosymbolic-systems
    진짜 마법은 더 근본적인 통합으로 갈 때 나올 것 같고, 우리 회사(https://onton.com)에서도 순수 기호도 조밀한 부동소수점 행렬도 아닌 통합 표현, 적은 양의 시끄러운 데이터에서 점진 학습하면서 catastrophic forgetting을 피하는 능력, 수학·기호 연산의 확실한 신뢰성, 환각 없음이라는 조건을 갖춘 LLM 이후 시스템을 고민 중임
    기존 시스템을 글루건처럼 이어 붙이는 방식도 유용하지만, 통합 아키텍처가 모든 것을 바꿀 것 같음

  • 정확성 계약 부분에 버그가 있음
    valid_opts = ['A', 'B', 'C'] 다음에 if v not in valid_sizes:가 나오는데, valid_sizes가 정의돼 있지 않음

    • 리팩터링 흔적이었고 지금은 고쳤음

  • “Symbolic AI”는 이미 잘 정의된 용어라 조금 아쉬움: https://en.m.wikipedia.org/wiki/Symbolic_artificial_intellig...

    • 그 점은 이해함
      이름을 바꿀 수도 있고, 논문에는 이름 선택에 대한 각주가 있음
      이 프로젝트에 영감을 준 Newell과 Simon의 기초 작업에 대한 크레딧을 담으려는 의도였음

  • 비용 구조가 궁금함
    자연어 계산이 들어간 줄을 실행할 때마다 LLM 추론 비용을 내는 건지, 외부 API를 쓰면 정말로 매번 과금되는 건지 알고 싶음
    예를 들어 루프 안에서 “symbolic” 함수를 호출하면 어떻게 되는지 궁금함

    • 맞음
      예를 들어 OpenAI를 쓰면 모든 의미 기반 연산이 OpenAI API 호출이 됨
      llama.cpp로 로컬 LLM을 호스팅한다면 모델 호스팅 비용 외의 추론 과금은 없음
    • 이건 어떤 형태로든 캐시가 필요할 것 같음

  • 요즘 코드는 LLM이 생성하니, 문맥을 담고 Python 연산자로 조작 가능한 Symbol 같은 특정 구문 구조가 사람이 검사와 균형 조건을 지시해 만든 일반 Python 코드보다 어떤 도움을 주는지 궁금함
    예를 들어 과일을 채소로 바꾸는 문법을 쓰는 대신, 과일 목록을 받아 내부에서 LLM을 호출해 대응되는 채소를 반환하는 프로그램을 만들라고 LLM에 프롬프트할 수도 있음
    차이를 이해하고 싶음

    • 환각 억제가 아닐까 싶음
      LLM이 형식 체계를 만들게 하면 범용 프로그램보다 훨씬 쉽게 검증할 수 있음

  • 진화할 수 있는 신경망-기호 AI도 고려해봤는지 궁금함
    https://deepwiki.com/dubprime/mythral/3.2-genome-system
    혹은 감정을 느끼는 쪽은 어떤지?
    https://deepwiki.com/search/how-do-emotives-work_193cb616-54...
    Marvin Minsky의 Society of Mind를 읽어봤는지도 궁금함

    • 짧게 답하면 모두 그렇다고 할 수 있음
      마음 이론에서 감정으로 이어지는 실험도 해봤지만, 지금은 모델이 아직 충분히 그 수준에 오지 않았다고 느껴서 노력 대비 수익이 줄어드는 바람에 멈춰 있음
      쉽게 되살릴 수는 있지만, Minsky가 최애는 아니고 그 세대에서는 Newell/Simon 쪽에 더 끌림
    • 그래도 설명 가능한 건지, 아니면 마법 같은 블랙박스인지가 중요함

  • LLM이 문서를 검토해 GitHub의 PySR(github.com/MilesCranmer/PySR)에 넣을 원시 연산자, 즉 연산자를 만들게 하는 기호 회귀를 조금 만져봤음
    전체를 연결하는 게 어려워서 멀리 가지는 못했지만, 이런 도구가 있으면 다시 시도해볼 수도 있겠음

    • 확실히 가능함
      계약을 쓰는 걸 추천함
      깨진 온톨로지 그래프를 반복적으로 “이어 붙이는” 계약에 비슷한 방식을 쓴 적이 있음
      영감을 줄 만한 데이터 모델로 Merge, Bridge, Prune, Operation 같은 구조를 두고, 각각 병합할 클러스터 인덱스와 상위-하위 클래스 관계, 가지치기할 클래스 목록을 정의한 뒤 검증기로 이항/단항 연산 조건을 강제했음
      비슷하게 연산자용 모델을 만들고, 계약이 한 번에 하나의 연산자를 풀게 한 다음 그 연산자를 적용하는 식으로 구성할 수 있음
답변달기