diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml index 0cb1449..ec68cdf 100644 --- a/.github/workflows/jekyll.yml +++ b/.github/workflows/jekyll.yml @@ -48,7 +48,7 @@ jobs: # together. If this assumption is ever wrong the build job fails and # `deploy` (needs: build) publishes nothing. - name: Setup Ruby - uses: ruby/setup-ruby@e81a8fa391b11a595c1b7ed84177cc0fe02faf83 # v1 + uses: ruby/setup-ruby@e81a8fa391b11a595c1b7ed84177cc0fe02faf83 # v1.328.0 # The version comes from .ruby-version (3.3+: html-proofer's # async→console dependency requires Ruby >= 3.3). with: @@ -89,7 +89,7 @@ jobs: # parse, that every page carries a description and a canonical, that no # two pages share a description or title, and that each plugin hook left # its mark on the posts (script/check-plugin-output.rb). Each check maps - # to a defect this site actually shipped. + # to a defect that shipped here or would ship silently. run: script/validate-site.sh ./_site - name: Upload artifact # Nothing to publish from a PR run; the gates above are the whole point. diff --git a/README.ko.md b/README.ko.md index 16c5d23..01b38d3 100644 --- a/README.ko.md +++ b/README.ko.md @@ -225,6 +225,8 @@ kramdown이 내용을 그대로 보존해 `\(…\)`로 내보내므로 안전합 디스플레이 `$$` 줄. - 마커 뒤에 언어 말고 다른 것이 붙은 코드 펜스, 닫히지 않은 펜스. - 게시일로 시작하지 않는 파일명, 그보다 늦은 `date:`. +- `href`가 이미지 `src`와 다른 직접 쓴 ``: 라이트박스가 그 페이지를 + iframe으로 열고 사이트가 이를 거부합니다. 출처는 캡션에 적습니다. - ar5iv 링크: ar5iv는 잃어버린 그림 대신 대체 이미지를 HTTP 200으로 돌려줍니다. `arxiv.org/html/v1/…`를 쓰거나 그림을 `assets/images/`에 복사합니다. diff --git a/README.md b/README.md index bccc3bf..71c5980 100644 --- a/README.md +++ b/README.md @@ -237,6 +237,8 @@ rules easiest to trip, each a page that renders wrong with every other gate gree a display `$$` line without blank lines around it. - a code fence with more than a language after the marker, or one never closed. - a file name that does not start with the posting day, or a `date:` after it. +- a hand-written `` whose `href` is not its image's `src`: the + lightbox loads the page in an iframe the site refuses. Credit the source in the caption. - an ar5iv link: ar5iv now answers a lost figure with a placeholder image and HTTP 200. Use `arxiv.org/html/v1/…`, or copy the figure into `assets/images/`. diff --git a/_includes/head.html b/_includes/head.html index 3b8968c..34387bc 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -83,7 +83,7 @@ })(); - {{ html_title }} + {{ html_title | escape }} {% if site.author %} diff --git a/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph-en.md b/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph-en.md index b04aec2..c422b83 100644 --- a/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph-en.md +++ b/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph-en.md @@ -271,7 +271,7 @@ One algorithm name is worth pinning down, at the fourth stage. Microsoft GraphRA A figure from Peng et al.'s survey maps the same skeleton in academic vocabulary, and it adds one axis between indexing, retrieval, and generation: whether to pull retrieval results as nodes, triples, paths, or subgraphs. The difference between LightRAG and PathRAG in §4.4 is exactly this axis. - + GraphRAG pipeline diagram. Starting from Graph Database and G-Indexing at lower left, flowing up into G-Retrieval (query expansion and decomposition, retrievers, merging and pruning). The middle Retrieval Results column lists nodes, triples, paths, subgraphs, and hybrids, while the Graph Format column converts to one of adjacency tables, natural language, code form, syntax trees, node sequences, or graph embeddings, feeding into G-Generation's pre-, mid-, and post-generation augmentation stages on the right to produce the final response. @@ -281,7 +281,7 @@ The [GA announcement](https://aws.amazon.com/blogs/machine-learning/announcing-g The architecture diagram in the AWS blog draws the managed boundary exactly. Inside the dotted box marked "Graph Knowledge Base (managed by Amazon Bedrock)" — chunking, embedding, entity extraction, and graph storage — everything belongs to the service. What the user touches is only S3 ingestion and querying, outside the box. - + Bedrock Knowledge Bases GraphRAG architecture diagram. PDF and CSV files on the left flow into Amazon S3 (raw data), and inside the dotted 'Graph Knowledge Base (managed by Amazon Bedrock)' region, chunks, embeddings, and entities are created and stored in Amazon Neptune. A user question on the right passes through Amazon Bedrock, queries this managed region, and returns as an answer. @@ -293,7 +293,7 @@ The middle ground holds open source toolkits. [AWS Labs' GraphRAG Toolkit](https There's a reason for listing all those names. What regaining control costs becomes tangible when you look at the toolkit's data model: instead of managed GraphRAG's three node types, you get six — Source, Chunk, Topic, Statement, Fact, Entity — plus relationships like `EXTRACTED_FROM`, `BELONGS_TO`, `SUPPORTS`, and `SUBJECT`/`OBJECT`, all of which you have to understand and maintain. Separating sentence-level Statements from the Facts that support them is what lets you trace an answer's evidence back to the source passage, and that traceability *is* the schema complexity. - + The graphrag-toolkit lexical graph data model. A Source at the top has multiple Chunks hanging off it via EXTRACTED_FROM, with Chunks linked to each other by NEXT and PREVIOUS. Topics in the middle point at Chunks via MENTIONED_IN, and Statements below attach to Topics via BELONGS_TO. Entities at the bottom form Facts through SUBJECT, OBJECT, and RELATION, and Facts support Statements via SUPPORTS. @@ -315,7 +315,7 @@ One [independent measurement](https://arxiv.org/abs/2502.11371) found constructi The first prescription came from KET-RAG itself, the same paper that produced the $33,000 estimate, and it's captured in their indexing diagram. Instead of sweeping the whole corpus with an LLM, extract only the key chunks with conventional GraphRAG to build a **KG skeleton**, and lay down a text-keyword bipartite graph over the rest using word tokenization with no LLM at all — a two-tier structure. At query time, a ratio $$\theta$$ splits how much gets retrieved from each tier: the expensive tier thin, the cheap tier thick. - + KET-RAG architecture diagram. In the indexing stage below, input text is (1) grouped into a KNN graph, then (2) only part of it becomes a KG Skeleton via conventional GraphRAG, while (3) word and sentence tokenization builds a Text-Keyword bipartite graph linking keywords like Juliet, Romeo, and Hamlet to text chunks. In the retrieval and generation stage above, a query, a length budget, and the retrieval ratio theta feed (4) retrieval from both tiers, then (5) the merged context goes to the LLM to produce the final answer. @@ -343,7 +343,7 @@ The third prescription comes from academic follow-ups. Where the first two touch What original GraphRAG and the two follow-ups just described pick up from the same graph is compressed into one figure from the PathRAG paper. Red marks what actually enters the prompt. - + Graph diagram comparing retrieval scope across three methods. In (a) GraphRAG, entire community ellipses are shaded red, pulling information at community granularity. In (b) LightRAG, nearly all neighbor nodes attached to query-relevant nodes like plants, aphids, and device are selected in red. In (c) PathRAG, only the thick red paths connecting those same query nodes remain, while surrounding nodes like sun, water, and oak stay blue and excluded. @@ -421,7 +421,7 @@ The mechanism behind it is a checkable claim: with metric calculation pinned dow The stack diagram Databricks published alongside shows the arrangement at a glance. Metric views — holding metric, dimension, and relationship modeling — sit as one layer inside the catalog, and three consumption paths (dashboards, Genie, SQL and notebooks) **all pass through that one layer** to get their numbers. The point is that metrics don't get redefined per path — and this arrangement, with metric definitions living inside the catalog, leads straight into the discovery and permission problems of the next section. - + Unity Catalog Business Semantics stack diagram. The large box below is Unity Catalog Business Semantics, and inside its dotted Metric views region, pre-computation for performance, measures and dimensions, and relationship modeling are stacked in layers. Three arrows rise from there to connect to the three consumption paths: AI/BI dashboards, Genie natural language queries, and SQL and notebooks. @@ -619,7 +619,7 @@ More uncomfortable is the variance between models. Same corpus, same procedure, The paper patches this fragmentation with post-processing: splitting compound nodes that swallowed whole sentences, then grouping scattered fragments under higher-level concepts. How one sentence changes through that process is captured in the paper's first figure. Take a sentence reporting that TV viewing at 12 months is negatively associated with cognitive ability at 4.5 years. Initial extraction produces one compound node lumping the whole sentence together (association between … and …). Splitting decomposes it into individual entities, and abstraction groups them under higher concepts like infant media exposure to connect the scattered islands. The color coding marks what entity deduplication, pronoun resolution, and provenance tracking each contribute at every stage. - + Diagram of triple changes as one sentence passes through three stages. From the example sentence at the bottom, Initial Extraction produces an 'association between …' compound node lumping the whole sentence together; Splitting decomposes it into reference triples pointing at individual entities; and Abstraction produces is_an_instance_of triples grouping them under higher concepts like 'infant media exposure' and 'child cognitive development'. The legend at right marks green as entity deduplication, purple as pronoun resolution, and orange as provenance tracking. @@ -660,7 +660,7 @@ The paper prescribes two remedies: route by query type, or integrate both result These outcomes mostly survive adding retrieval post-processing. The same evaluation crossed in two techniques. **Reranking** rescores retrieved chunks to change their order. **IRCoT** alternates retrieval and reasoning, asking after each round what else to look for given the evidence gathered so far, rather than answering in one shot. Both were applied, and the per-query-type advantages held. - + Two line charts comparing QA performance by reasoning strategy. On the left, NQ (single-hop), vector RAG maintains the highest F1 across all three strategies (Rerank, Vanilla, IRCoT). On the right, MultiHop-RAG (multi-hop), graph-based HippoRAG2 is highest across all three. Changing strategy preserves the ordering among methods, except that MultiHop-RAG's Community-GraphRAG (Local) drops below Vanilla under IRCoT. diff --git a/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph.md b/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph.md index 13cfa65..e370a3f 100644 --- a/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph.md +++ b/_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph.md @@ -271,7 +271,7 @@ LLM으로 그래프를 자동 구축하는 파이프라인은 다섯 단계로 같은 뼈대를 학계 쪽 어휘로 그린 지도가 Peng et al. 서베이의 그림입니다. 인덱싱·검색·생성 사이에 축이 하나 더 놓여 있다는 게 요점입니다 — 검색 결과를 노드·트리플·경로·부분그래프 중 무엇으로 뽑을 것인가. §4.4에서 볼 LightRAG·PathRAG의 차이가 정확히 이 축에서 갈립니다. - + GraphRAG 파이프라인 도식. 왼쪽 아래 Graph Database와 G-Indexing에서 시작해 위쪽 G-Retrieval(질의 확장·분해, 검색기, 병합·가지치기)로 올라가고, 가운데 Retrieval Results 열에 노드·트리플·경로·부분그래프·혼합이 나열되며, Graph Format 열은 인접 테이블·자연어·코드 형태·구문 트리·노드 시퀀스·그래프 임베딩 중 하나로 변환한 뒤 오른쪽 G-Generation의 생성 전·중·후 보강 단계로 이어져 최종 응답을 만든다. @@ -282,7 +282,7 @@ LLM으로 그래프를 자동 구축하는 파이프라인은 다섯 단계로 AWS 블로그에 실린 구성도가 이 관리형의 경계를 그대로 보여 줍니다 — 점선 상자로 묶인 "Graph Knowledge Base (managed by Amazon Bedrock)" 안쪽, 즉 청킹·임베딩·엔티티 추출과 그래프 저장이 전부 서비스 몫입니다. 사용자가 만지는 건 상자 밖의 S3 적재와 질의뿐입니다. - + Bedrock Knowledge Bases GraphRAG 구성도. 왼쪽의 PDF·CSV 파일이 Amazon S3(raw data)로 들어가고, 점선으로 묶인 'Graph Knowledge Base (managed by Amazon Bedrock)' 영역 안에서 청크·임베딩·엔티티가 만들어져 Amazon Neptune에 저장된다. 오른쪽 사용자가 던진 질문은 Amazon Bedrock을 거쳐 이 관리형 영역을 조회한 뒤 답으로 돌아온다. @@ -295,7 +295,7 @@ AWS 블로그에 실린 구성도가 이 관리형의 경계를 그대로 보여 이름을 이렇게 늘어놓은 이유가 있습니다. 제어권을 되찾는 대가가 무엇인지는 이 툴킷의 데이터 모델을 보면 실감이 납니다 — 관리형의 chunk·document·entity 세 종류 대신, Source·Chunk·Topic·Statement·Fact·Entity 여섯 종류와 `EXTRACTED_FROM`·`BELONGS_TO`·`SUPPORTS`·`SUBJECT`/`OBJECT` 같은 관계까지 사용자가 이해하고 관리해야 합니다. 문장 단위 Statement와 그것을 떠받치는 Fact를 분리해 둔 덕에 답의 근거를 원문 조각까지 되짚을 수 있는데, 그 추적성이 곧 스키마 복잡도입니다. - + graphrag-toolkit의 렉시컬 그래프 데이터 모델. 맨 위 Source에 여러 Chunk가 EXTRACTED_FROM으로 매달리고 Chunk끼리 NEXT·PREVIOUS로 이어진다. 가운데 Topic이 MENTIONED_IN으로 Chunk를 가리키고, 아래 Statement들이 BELONGS_TO로 Topic에 붙는다. 맨 아래 Entity들이 SUBJECT·OBJECT·RELATION으로 Fact를 이루고, Fact가 SUPPORTS로 Statement를 떠받친다. @@ -317,7 +317,7 @@ AWS 블로그에 실린 구성도가 이 관리형의 경계를 그대로 보여 첫째 처방은 $33,000을 추정한 KET-RAG 연구진이 내놨고, 그 구조가 논문의 인덱싱 그림에 담겨 있습니다. 코퍼스 전체를 LLM으로 훑는 대신 핵심 조각들만 기존 GraphRAG로 뽑아 **KG Skeleton**(골격 그래프)을 만듭니다. 나머지는 LLM 없이 단어를 토큰화해 텍스트-키워드 이분 그래프로 구성합니다. 질의 시점에는 두 층에서 각각 얼마씩 회수할지를 비율 $$\theta$$로 나눠 씁니다. 비싼 층은 얇게, 값싼 층은 두껍게 긁는 셈입니다. - + KET-RAG 구조도. 아래 인덱싱 단계에서 입력 텍스트가 ① KNN 그래프로 묶인 뒤 ② 기존 GraphRAG로 일부만 KG Skeleton이 되고, ③ 단어·문장 토큰화로 Juliet·Romeo·Hamlet 같은 키워드와 텍스트 조각을 잇는 Text-Keyword 이분 그래프가 만들어진다. 위 검색·생성 단계에서는 질의와 길이 한도, 회수 비율 세타를 입력받아 ④ 두 층에서 각각 회수한 뒤 ⑤ 맥락을 합쳐 LLM에 넣고 최종 답을 만든다. @@ -345,7 +345,7 @@ LazyGraphRAG의 발상을 조금 더 풀어 보면 왜 이게 통하는지 보 원조 GraphRAG와 방금 본 두 후속(LightRAG·PathRAG)이 같은 그래프에서 무엇을 집어 오는지를 PathRAG 논문의 그림 하나가 압축해 보여 줍니다. 빨간색이 프롬프트에 실제로 들어가는 부분입니다. - + 세 방식의 회수 범위를 비교한 그래프 도식. (a) GraphRAG는 커뮤니티 타원 전체가 빨갛게 칠해져 커뮤니티 단위로 정보를 가져오고, (b) LightRAG는 plants·aphids·device 같은 질의 관련 노드에 붙은 이웃 노드가 거의 다 빨갛게 선택되며, (c) PathRAG는 같은 질의 노드들을 잇는 굵은 빨간 경로만 남고 sun·water·oak 같은 주변 노드는 파란색으로 제외된다. @@ -423,7 +423,7 @@ dbt Labs가 2026년 4월 [Sequeda의 ACME Insurance 벤치마크를 다시 돌 Databricks가 함께 실은 스택 그림을 보면 이 구조를 한눈에 파악할 수 있습니다. 지표·차원·관계 모델링을 담은 Metric views는 카탈로그 안에 하나의 층으로 놓입니다. 대시보드, Genie, SQL/노트북이라는 세 소비 경로는 **모두 그 한 층을 거쳐** 숫자를 받습니다. 경로마다 지표를 다시 정의하지 않는다는 것이 요점입니다. 지표 정의를 카탈로그 안에 둔 이 구조는 다음 장에서 다룰 발견과 권한 문제로 이어집니다. - + Unity Catalog Business Semantics 스택 도식. 아래쪽 큰 상자가 Unity Catalog Business Semantics이고 그 안의 점선 영역 Metric views에 성능용 사전 계산, 측정값(Measures)과 차원(Dimensions), 관계 모델링이 층으로 쌓여 있다. 거기서 화살표 셋이 위로 올라가 AI/BI 대시보드, Genie 자연어 질의, SQL·노트북 세 소비 경로로 각각 연결된다. @@ -624,7 +624,7 @@ $$\mathrm{score}(d) = \sum_{r} \frac{w_r}{60 + \mathrm{rank}_r(d)}$$ 논문은 이 흩어짐을 후처리로 메웁니다. 문장을 통째로 삼킨 덩어리(compound) 노드를 쪼개고, 흩어진 조각들을 상위 개념으로 묶는 두 단계입니다. 한 문장이 그 과정을 거치며 어떻게 달라지는지가 논문의 첫 그림에 그대로 담겨 있습니다. 생후 12개월 TV 시청이 4.5세 인지능력과 음의 상관을 보인다는 문장을 놓고, 초기 추출은 문장 전체를 뭉친 덩어리 노드(association between … and …) 하나를 만들어 버립니다. 쪼개기(splitting)가 그걸 개별 엔티티로 분해하고, 추상화(abstraction)가 유아 미디어 노출 같은 상위 개념으로 묶어 흩어진 섬들을 잇습니다. 색으로 표시된 엔티티 중복 제거·대명사 해소·출처 추적이 각 단계에서 하는 일입니다. - + 한 문장이 세 단계를 거치는 트리플 변화 도식. 맨 아래 예시 문장에서 초기 추출(Initial Extraction)은 문장 전체를 뭉친 'association between …' 덩어리 노드를 만들고, 쪼개기(Splitting)는 그것을 개별 엔티티를 가리키는 reference 트리플들로 분해하며, 추상화(Abstraction)는 'infant media exposure'·'child cognitive development' 같은 상위 개념으로 묶는 is_an_instance_of 트리플을 만든다. 오른쪽 범례는 초록이 엔티티 중복 제거, 보라가 대명사 해소, 주황이 출처 추적임을 표시한다. @@ -665,7 +665,7 @@ $$\mathrm{score}(d) = \sum_{r} \frac{w_r}{60 + \mathrm{rank}_r(d)}$$ 이 승패는 검색 후처리를 얹어도 대체로 뒤집히지 않습니다. 같은 평가가 후처리 두 가지까지 교차해 봤습니다. **재순위화(reranking)**는 회수한 조각을 다시 점수 매겨 순서를 바꿉니다. **IRCoT**는 한 번에 답하지 않고, 지금까지 모은 근거로 다음에 무엇을 더 찾아야 하는지를 되물으며 검색과 추론을 번갈아 돌립니다. 둘 다 얹어 봤지만 질의 유형별 우위 관계는 그대로였습니다. - + 추론 전략별 QA 성능을 비교한 두 개의 꺾은선 그래프. 왼쪽 NQ(단일 홉)에서는 Rerank·Vanilla·IRCoT 세 전략 모두에서 벡터 RAG가 가장 높은 F1을 유지하고, 오른쪽 MultiHop-RAG(멀티홉)에서는 그래프 기반 HippoRAG2가 세 전략 모두에서 가장 높다. 전략을 바꿔도 방법 사이의 순서는 유지되지만, MultiHop-RAG의 Community-GraphRAG(Local)만 IRCoT에서 Vanilla보다 낮게 떨어진다. diff --git a/_sass/_layout.scss b/_sass/_layout.scss index 97281c3..f5e2999 100644 --- a/_sass/_layout.scss +++ b/_sass/_layout.scss @@ -895,6 +895,7 @@ blockquote { .share, .post-nav, .related-posts, + .code-copy, .site-footer { display: none !important; } diff --git a/_sass/_post.scss b/_sass/_post.scss index 191628b..cb007d2 100644 --- a/_sass/_post.scss +++ b/_sass/_post.scss @@ -395,4 +395,38 @@ line-height: 1.4; } } -} \ No newline at end of file +} + +// The lightbox (GLightbox's sheet loads after this one). A figure with a +// transparent background gets the white paper it was drawn on here too; the +// focus ring is the site's light blue on the black overlay (GLightbox's +// #0f3d81 reaches 1.8:1); the buttons are opaque over a wide white figure and +// drop the padding every