RAG

주제별로 노트를 정리하는 것은 논리적으로 들리지만, PostgreSQL에 대한 노트가 다섯 개의 다른 폴더에 흩어져 있어 오늘 해결해야 할 문제에 도움이 되는 노트를 찾을 수 없게 된다면 이야기가 달라집니다.

메모리는 어시스턴트를 반응형에서 지속형으로 전환시키지만, 동시에 많은 시스템이 조용히 부패하는 곳이기도 합니다. 설문 조사들은 단기적 대 장기적 이분법이 현대 에이전트 메모리에는 더 이상 충분하지 않다고 주장하며, OpenAI와 LangGraph SDK들은 작동 메모리(working memory), 내구 상태(durable state), 검색(retrieval)이라는 더 단순한 스택을 지향합니다.

프로덕션 환경의 AI 어시스턴트는 단순히 “프롬프트가 붙은 LLM"이 아닙니다. 의도(intent)를 수용하고, 상태를 유지하며, 언제 검색하거나 행동을 취할지 결정하는 시스템입니다. 또한 실패 원인을 디버깅할 수 있도록 충분한 런타임 세부 정보를 노출해야 합니다.

AI는 지식 관리를 대체하지 않습니다. 대신 개인과 팀 모두에게 지식 관리의 형태를 변화시키고 있습니다.

대부분의 현대 지식 시스템은 검색(Retrieval) 최적화에 집중하며, 이는 이해할 수 있는 접근입니다. 검색은 가시적이며 데모하기 쉽고, 작동할 때 마법처럼 느껴집니다. 질문을 입력하면 답변이 돌아옵니다.

전제는 간단합니다. 컴파일된 지식은 검색된 단편보다 재사용성이 높습니다. RAG는 직관적인 질문—LLM에게 외부 지식을 어떻게 접근하게 할 것인가?—에 대한 기본 답변이 되었습니다.

PKM, RAG, 위키(Wiki), AI 메모리 시스템, 그리고 최근 주목받는 실용적인 AI 지원 워크플로우가 마치 동일한 문제를 해결하는 것처럼 자주 논의됩니다. 하지만 사실 그렇지 않습니다. 이들은 모두 지식과 관련되어 있지만, 서로 다른 계층에서 작동합니다:

정보 과잉 문제는 양 자체보다 해결되지 않은 입력들의 문제입니다. 현대의 지식 작업은 탭, 채팅 스레드, 문서, 하이라이트, 스니펫, 전사본, 스크린샷, 그리고 완성되지 않은 노트들의 흔적을 남깁니다.

대부분의 대규모 언어 모델(LLM) ‘구조화된 출력(structured output)’ 튜토리얼은 진지하지 않습니다. 이들은 사용자에게 정중하게 JSON을 요청한 후 모델이 잘 작동하기를 바라고 만듭니다. 그것은 검증(validation)이 아닙니다. 그것은 중괄호를 사용한 낙관주의에 불과합니다.

검색 증강 생성 (RAG)을 공부 중이시라면, 이 섹션에서는 텍스트 임베딩이 무엇인지, 검색 및 검색 (retrieval) 과 어떻게 연관되는지, 그리고 Ollama 또는 OpenAI 호환 HTTP API(많은 llama.cpp 기반 서버에서 제공하는 방식) 를 사용하여 Python에서 두 가지 일반적인 로컬 설정을 호출하는 방법을 쉽게 설명합니다.

Neo4j 는 관계가 곧 데이터일 때 찾아야 할 솔루션입니다. 도메인이 원과 화살표로 가득 찬 화이트보드처럼 보인다면, 이를 테이블로 강제하는 것은 고통스럽습니다.

대부분의 로컬 AI 설정은 모델과 런타임에서 시작합니다.

OpenClaw는 Ollama와 같은 로컬 LLM 런타임이나 Claude Sonnet과 같은 클라우드 기반 모델과 함께 실행하도록 설계된 셀프 호스팅(Self-hosted) AI 어시스턴트입니다.

대부분의 로컬 AI 환경은 동일한 방식으로 시작합니다. 모델, 런타임, 그리고 채팅 인터페이스가 그것입니다.

Chunking은 Retrieval ‑ Augmented Generation (RAG)에서 가장 과소평가되는 하이퍼파라미터입니다: 이는 조용히 LLM이 “보는” 내용을 결정하며, 데이터의 인gestion 비용을 얼마나 많이 증가시키는지, 그리고 각 답변당 LLM의 컨텍스트 창을 얼마나 많이 소모하는지를 결정합니다.

Production-focused guide to building RAG systems: chunking, vector stores, hybrid retrieval, reranking, evaluation, and when to choose RAG over fine-tuning.