이 챕터의 thesis는 단순하다. LLM은 KG를 직접 생산하지 않는다. LLM은 KG를 만들기 위한 중간 산출물(metagraph)을 생산하고, 정규화·entity resolution을 거쳐야 비로소 KG가 된다.이전 편까지 vector RAG와 graph RAG의

이전 챕터까지 다룬 KG는 테이블·관계형 DB·기존 knowledge base 같은 구조화된 데이터를 전제로 했다. 그러나 실무에서 마주하는 도메인 지식 대부분은 논문·보고서·아카이브 문서 같은 비정형 텍스트에 잠겨 있다. 이 챕터의 thesis는 다음과 같다. 비정형

단일 출처 그래프는 정보를 저장하지만, 다중 소스 통합 KG는 정보를 연결한다.이전까지의 논의가 단일 도메인·단일 출처에서 knowledge graph(KG)를 구축하는 방법에 머물렀다면, 이 챕터는 이질적인 데이터셋을 하나의 동질 그래프(homogeneous grap

Knowledge Graph 구축의 본질적 난점은 단순한 포맷 변환이 아니라 의미(semantics)의 통합에 있다. 책에서는 이 난점을 네 층위로 분해한다.포맷 차이: XML, CSV, JSON 등 직렬화 형식이 제각각이다.저장 기술 차이: 관계형 DB와 문서지향 D

임베딩은 의미를 고차원 공간에 새기고, 그래프는 그 사이를 잇는다. Neo4j Vector Index는 두 검색 방식을 한 데이터베이스 안에서 결합한다.Neo4j Vector Index는 vector 기반 유사도 검색과 graph traversal을 하나의 storag

Neo4j 기반 그래프 분석 환경은 네 가지 축으로 구성된다. 데이터베이스 엔진, 플러그인 라이브러리, 클라이언트 인터페이스, 언어 바인딩이 그것이다.각 구성 요소는 독립적으로 교체 가능하다. 실행 환경(Desktop vs Aura), 플러그인의 활성화 여부, 접근 인

그래프 기반 시스템을 다루기에 앞서, 그래프 자료구조의 정의를 명확히 할 필요가 있다. 관계 자체를 일급 객체로 취급하는 데이터 모델이 그래프이다.이산수학과 그래프 이론에서 그래프는 객체(node)와 그 객체들 사이의 연결(relationship)로 구성된 구조로 정의

ChatGPT한테 "우리 회사 작년 계약서 내용 좀 정리해줘"라고 물어봤다가, 알고 보니 절반은 지어낸 내용이었던 적 있으시죠? 또는 분명 회사 위키에 있는 내용인데도 AI가 "그런 정보는 없어요"라고 답해서 답답했던 경험도요.이 문제, 사실 AI가 멍청해서가 아닙니다

Prompt Engineering과 Fine-tuning을 두 축으로 LLM 기반 Text-to-SQL의 전체 파이프라인을 체계화한 ACM Computing Surveys 서베이이 서베이를 효과적으로 읽기 위해 필요한 개념을 정리한다.Prompt Engineering:

Text-to-SQL의 전 생애주기(모델·데이터·평가·오류분석)를 LLM 관점에서 체계적으로 재정리한 서베이이 서베이를 효과적으로 읽기 위해 알아두면 좋은 개념들이다.Text-to-SQL (NL2SQL): 자연어 질의를 실행 가능한 SQL로 변환하는 과제. 데이터베이스

1편(이번 편의 출발점은 그 다음 질문이다. 그래서 그 원본 CoT를 API 응답에 어떻게 담고, UI에는 무엇을 노출할 것인가? 이 질문이 까다로운 이유는 CoT가 본질적으로 충돌하는 두 가지 성격을 동시에 가지기 때문이다.한쪽에서 CoT는 모델 성능에 필요하다. 도

gpt-oss는 Harmony 포맷 없이는 동작하지 않는다. 역할·채널·특수 토큰을 한 번에 정리한다.gpt-oss 모델은 Harmony 응답 포맷으로 학습되었다. 즉, 이 포맷은 "권장 사항"이 아니라 모델이 정상 동작하기 위한 전제 조건이다. 다른 포맷으로 입력을

vector RAG는 의미가 비슷한 chunk를 모아오고, graph RAG는 관계를 따라 추론한다. 두 retrieval은 서로 다른 질문에 답한다.LLM 기반 챗봇은 단순 질의응답을 넘어 AI agent 형태로 진화하고 있다. AI agent는 환경과 상호작용하면서

지능형 시스템(intelligent system)은 사용자를 AI/ML과 연결해 의미 있는 목적을 달성하는 시스템으로 정의된다. 핵심 속성은 사용자와의 상호작용을 관찰하며 시간에 따라 지능이 진화한다는 점이다. 외부에서 보면 복잡한 작업을 수행하는 black box이지

RAG(Retrieval-Augmented Generation)는 외부 지식을 LLM에 주입해 hallucination을 줄이는 기법이다. 그러나 "외부 지식을 어떻게 표현하고 검색하는가"에 따라 두 갈래로 나뉜다.Vector RAG: 텍스트를 chunk로 쪼개 emb

파이썬의 슬라이싱(list\[start:end:step])은 강력합니다. 리스트, 문자열, 튜플, bytes 등 시퀀스 타입이면 다 통하죠. 그런데 다른 언어에서 배열을 다루던 습관이 남아 있으면 필요 없는 0이나 len()을 끝까지 꾸역꾸역 쓰는 코드가 나옵니다. 틀

파이썬에는 C에서 물려받은 이상한 기능이 하나 있습니다. 문자열 리터럴 두 개가 나란히 붙어 있으면 자동으로 하나로 합쳐지는 것. "hello" "world"라고 쓰면 + 없이도 "helloworld"가 됩니다. 얼핏 보면 편리해 보이지만, 이게 리스트 안에서 쉼표 하

디버깅하려고 print(some_value)를 찍었는데, 숫자 5와 문자열 "5"가 똑같이 5로 출력돼서 타입 때문에 벌어진 버그를 놓친 경험, 한 번쯤 있으실 거예요. 아니면 내가 만든 클래스를 print했더니 <\_\_main\_\_.User object at

파이썬에는 문자열에 변수를 끼워 넣는 방법이 4가지나 있습니다. % 연산자(C 스타일), str.format(), f-string, 그리고 최근에 추가된 t-string까지. 옛날 코드베이스에서는 %s, %d를 자주 볼 수 있고, 중간 세대 코드에서는 "{name}".

파일에서 데이터를 읽다가 TypeError: a bytes-like object is required, not 'str' 에러를 만난 적 있나요? 아니면 HTTP 응답을 파싱하는데 b'...' 형태로 나와서 .replace()가 먹히지 않아 당황했던 적은요? 파이썬의