이 글은 LightMem: Lightweight and Efficient Memory-Augmented Generation을 정리한 글입니다. LLM 에이전트에게 대화 이력을 기억시키는 가장 손쉬운 방법은 과거 대화를 통째로 프롬프트에 다시 넣는 것입니다. 문제는 대화가 길어질수록 이 방식이 그대로 무너진다는 점입니다. 컨텍스트가 길어지면 중간에 있는 정보를 놓치는 “Lost in the Middle” 현상이 나타나고, 매번 쌓인 이력을 다시 읽어들이는 기존 메모리 시스템들은 연산량이 커지면서 응답 속도까지 떨어집니다. LightMem은 이 두 문제를 동시에 겨냥한 경량 메모리 생성 시스템으로, 토큰 사용량을 기존 시스템 대비 수십 분의 일 수준으로 줄이면서도 더 나은 성능을 냅니다. ...

Discussion: Reddit (r/java) · Hacker News This is Part 3 of a series on building a high-performance hash table for the JVM. Part 1 — Building a Fast, Memory-Efficient Hash Table in Java (by borrowing the best ideas): designing a SwissTable-style map from scratch — control bytes, SWAR probing, and why open addressing beats chaining for cache locality. Part 2 — Further Optimizing my Java SwissTable: Profile Pollution and SWAR Probing: hunting down a surprising Objects.equals() hotspot, and why SWAR beat the Vector API on both ARM and x86. Part 3 (this post): handing the profiler to an AI agent — and what it found. Part 3: letting the agent drive At the end of the last post, I had a SwissMap that felt genuinely fast: the Objects.equals() profile pollution was gone, SWAR had beaten the Vector API on both ARM and x86, and I finally had benchmarks I was willing to trust. ...

그래프 연산이나 저장 구조를 최적화할 때 빠지지 않고 등장하는 자료구조가 CSR(Compressed Sparse Row)입니다. 1977년 예일 대학교가 발표한 Yale Sparse Matrix Package 보고서에서 처음 소개되어 Yale Format이라고도 불리는데, 희소 행렬(sparse matrix)을 효율적으로 저장하고 처리하기 위해 고안되었습니다. 희소 행렬이란 희소 행렬은 대부분의 원소가 0인 행렬을 말합니다. 과학 계산, 그래프 이론, 머신러닝 등 현대 컴퓨팅의 거의 전 영역에서 마주치게 되는데, 현실의 데이터를 행렬로 옮기면 십중팔구 이런 모양이 됩니다. SNS를 예로 들면, 사용자가 100만 명이라 해도 한 사람의 친구 수는 보통 500명 안팎입니다. 그런데 이것을 그대로 행렬로 표현하려면 1조(10^12) 크기, 그러니까 7.3PB에 달하는 행렬이 필요해집니다. 실제 정보량에 비해 저장 공간이 터무니없이 커지는 셈입니다. ...

이 글은 구글이 2017년 KDD에서 발표한 논문 Ego-Splitting Framework: from Non-Overlapping to Overlapping Clusters를 정리한 글입니다. 왜 비중첩 클러스터링만으로는 부족한가 현실의 네트워크에는 보통 중간 크기(대략 100명 안팎)의 커뮤니티가 다수 존재하고, 하나의 노드가 여러 커뮤니티에 동시에 걸쳐 있는 경우가 흔합니다. 그런데 기존의 비중첩(non-overlapping) 클러스터링 알고리즘들은 각 노드를 정확히 하나의 커뮤니티에만 배정하기 때문에, 이런 실제 네트워크 구조를 제대로 포착하지 못합니다. 물론 중첩(overlapping) 클러스터링을 시도하는 알고리즘들도 이미 여럿 있었지만, 대체로 지나치게 복잡하거나 유연성이 떨어졌고, 이론적인 보장도 부족했습니다. ...

그래프 안에서 서로 밀접하게 연결된 노드들의 집합, 즉 커뮤니티를 찾아내는 문제를 Community Detection이라고 부릅니다. 일종의 클러스터링 문제로 볼 수 있는데, GraphRAG 같은 방법론이 지식 그래프를 다룰 수 있는 단위로 쪼개는 데 바로 이 기법을 사용합니다. 이 글에서는 Community Detection에서 가장 널리 쓰이는 지표인 Modularity가 어떤 발상에서 나왔는지, 그리고 이를 최적화하는 대표적인 알고리즘인 Louvain과 Leiden이 어떻게 다른지 살펴보겠습니다. Modularity: 커뮤니티가 잘 만들어졌는지 재는 법 커뮤니티를 하나 만들었다고 해봅시다. 이 커뮤니티가 “잘” 만들어졌다는 건 어떤 의미일까요? Community Detection에서 가장 널리 쓰이는 답은 Modularity라는 지표입니다. 직관은 단순합니다. 만약 그래프의 엣지들이 완전히 무작위로 연결되어 있었다면 이 커뮤니티 안에 몇 개의 엣지가 있었을지 계산해두고, 실제로 관찰된 엣지 수가 그 기댓값보다 얼마나 더 많은지를 재는 것입니다. 우연이라고 보기 힘들 정도로 연결이 조밀하다면, 그건 진짜 커뮤니티라고 볼 근거가 됩니다. ...

이 글은 마이크로소프트 리서치의 논문 From Local to Global: A GraphRAG Approach to Query-Focused Summarization과, 서울대학교 산업공학과 DSBA 연구실의 [Paper Review] GraphRAG 영상을 참고해 정리한 글입니다. RAG는 신뢰할 수 있는 문서 집합을 구축해두고, 질문이 들어오면 관련 문서를 찾아 LLM에게 근거로 제공해 답을 생성하게 하는 방식입니다. 인덱싱(문서를 chunking해서 검색 가능한 형태로 저장), Retrieval(질문과 관련된 문서를 탐색), Generation(탐색된 문서와 질문을 바탕으로 답변을 생성)이 기본 구성 요소입니다. 기존 RAG의 한계 RAG의 발전은 대체로 “질문의 의도를 어떻게 더 정확히 파악할 것인가"와 “질문과 연관된 문서를 어떻게 더 잘 찾을 것인가"에 초점을 맞춰 이뤄져 왔습니다. 문서 하나하나를 더 잘 찾는 데는 강했지만, 정작 문서들 사이의 관계나 연결성에는 상대적으로 관심이 적었습니다. ...

이 글은 SimpleMem: Efficient Lifelong Memory for LLM Agents을 읽고 리뷰한 글입니다. 현재는 논문의 일부 내용이 수정되어 작성 시점(2026.01.24)과 상이할 수 있습니다. 배경 LLM은 기본적으로 상태를 유지하지 않는(stateless) 특성을 갖고 있습니다. 따라서 이전 추론 결과가 다음 추론 결과에 영향을 주지 않습니다. 이러한 특성으로 인해, LLM을 그냥 사용하면 대화가 연속적으로 이어지지 못하는 문제가 발생할 수 있습니다. 즉, 나와 방금 나눈 대화를 기억하지 못하는 초단기 기억상실증과 같은 모습을 보이는 것입니다. 연구자들은 간단한 방법으로 이 문제를 해결하였습니다. 바로 사용자와 LLM 에이전트 사이의 대화 이력을 별도의 공간(e.g. 메모리)에 저장하고, 매 추론마다 입력 프롬프트에 과거 대화 이력을 주입함으로써 LLM으로 하여금 연속적인 대화가 가능하도록 만든 것입니다. ...

Discussions Hacker News Reddit The next milestone is to build a fully thread-safe hash map. Up to this point, the focus has been entirely on single-threaded performance: minimizing memory overhead, improving cache locality, and squeezing out every last bit of throughput from the underlying data layout. However, real-world applications rarely stay single-threaded. To be practically useful, a hash map must behave correctly—and efficiently—under concurrent access. Before jumping straight into implementation, it’s worth stepping back and studying how existing thread-safe hash map implementations approach this problem. Different designs make different trade-offs between simplicity, scalability, memory usage, and read/write performance. By examining these approaches side by side, we can better understand which ideas scale cleanly—and where the pitfalls are—when multiple threads hit the same structure at once. ...

Discussions Reddit Part 2: optimizing the hot path (and finding a weird villain) “Why Objects.equals() showed up in the profile, and why SWAR beat the Vector API on ARM (and x86).” In the last post, I finally got a SwissTable-ish map running on the JVM and fast enough to make me smile. Naturally, that meant I immediately started staring at the profiler again, thinking: okay… but how do I make it faster? ...

Discussions Hacker News Reddit One day, I ran into SwissTable, the kind of design that makes you squint, grin, and immediately regret every naive linear-probing table you’ve ever shipped. This post is the story of how I tried to bring that same “why is this so fast?” feeling into Java. It’s part deep dive, part engineering diary, and part cautionary tale about performance work. 1) The SwissTable project, explained the way it feels when you first understand it SwissTable is an open-addressing hash table design that came out of Google’s work and was famously presented as a new C++ hash table approach (and later shipped in Abseil). ...