<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Llm-Wiki on cdeclog</title><link>https://cdecl.github.io/tags/llm-wiki/</link><description>Recent content in Llm-Wiki on cdeclog</description><generator>Hugo -- 0.168.0</generator><language>ko-kr</language><lastBuildDate>Mon, 26 Oct 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://cdecl.github.io/tags/llm-wiki/index.xml" rel="self" type="application/rss+xml"/><item><title>LLM Wiki 실전 가이드: RAG의 한계를 넘는 누적 지식 베이스 구축과 운영 패턴</title><link>https://cdecl.github.io/devops/llm-wiki-architecture-and-practice/</link><pubDate>Mon, 26 Oct 2026 00:00:00 +0900</pubDate><guid>https://cdecl.github.io/devops/llm-wiki-architecture-and-practice/</guid><description>&lt;p&gt;최근 LLM을 문서와 연동할 때 표준처럼 쓰이던 RAG(Retrieval-Augmented Generation)의 한계를 느끼는 엔지니어들이 늘고 있습니다. 문서를 잘게 쪼개어 벡터 DB에 넣고 질의할 때마다 검색하는 방식은 간단하지만, **&amp;ldquo;매번 처음부터 새로 읽고 조합해야 하며, 질문을 거듭해도 지식이 스스로 누적되지 않는다&amp;rdquo;**는 구조적 한계가 있기 때문입니다.&lt;/p&gt;
&lt;p&gt;이 문제를 해결하기 위해 Andrej Karpathy가 제안한 아이디어가 바로 &lt;strong&gt;LLM Wiki&lt;/strong&gt;입니다. LLM Wiki는 검색기가 아니라, 사람이 던져 넣은 원본 자료를 바탕으로 LLM이 마크다운 위키를 지속해서 작성·갱신·교차 검증하며 &lt;strong&gt;지식을 복리처럼 쌓아가는 패턴&lt;/strong&gt;입니다.&lt;/p&gt;</description></item></channel></rss>