피터의 개발이야기

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며나는 AI를 잘 운영하는 개발자로 성장하기위해 노력하고 있다.그래서 지난 글 [AI] 1000개 블로그 글을 LLM Wiki로 만든 이야기 — Karpathy의 아이디어를 실전에 적용하다에서1,000개 문서짜리 제 Obsidian Wiki를 만들었다.이번엔 그 위에 로컬 RAG 챗봇을 올렸다.이 글은 그 구축 기록이고, 동시에 왜 Vercel을 버리고 맥미니 + Cloudflare Tunnel로 갔는지에 대한 기록이다. 내가 공부한 llm모델의 임베딩, 로컬 시스템으로 연동하여 나에게 필요한 백터디비의 사양을 파악하는 연습을 하기 위해서다. 우리집 맥미니 M1 8GB에서 local LLM으로 가동 중이다. peterica-blog-chat ㅁ 요..

[AI] Peterica의 AI공부와 비젼 정리ㅁ 들어가며 Sakana AI의 Doc-to-LoRA(D2L) 프로젝트를 살펴보면서, 기존에 내가 익숙하게 사용하던 RAG 구조를 다시 생각하게 되었다.문서를 검색해서 프롬프트에 붙이는 방식이 아니라, 문서를 모델 내부에 반영한다는 접근은 단순한 개선이 아니라 방향 자체가 다르게 느껴졌다. 특히 인상적이었던 점은,이 방식이 DB의 옵티마이저처럼 “실행 전에 구조를 바꿔 효율을 높인다”는 점에서는 유사하지만,결과적으로는 단순한 성능 개선이 아니라 결과 자체를 바꾼다는 점에서 전혀 다른 레벨의 기술이라는 것이었다. 이 글은 그 차이를 이해하기 위해 정리한 개인적인 학습 기록이다. ㅁ 우리가 익숙한 방식 — RAG는 무엇을 하고 있는가일반적인 LLM 시스템은 ..

[AI] Peterica의 AI공부와 비젼 정리 ㅁ 들어가며나는 백엔드 개발자로 시작했고, DevOps와 SRE 성격의 업무를 거치며 서비스 운영을 경험해 왔다.그러다 최근 LLM 기반 시스템을 직접 설계하면서 관점이 바뀌었다.AI는 더 이상 “모델 호출”이 아니라운영 대상 시스템이라는 생각이 들기 시작했다.그래서 개인적으로 LLM 학습 노트를 만들었다.단순 이론 정리가 아니라, 실제 서비스를 만들고 운영한다는 관점에서 정리한 기록이다. ㅁ 왜 LLM 학습 노트를 만들었나처음에는 RAG 구현이 목적이었다.하지만 파고들수록 느꼈다.Retriever 품질은 Embedding과 Chunking에서 결정되고RAG 성능은 VectorDB 튜닝과 Reranking에서 갈리며최종 응답 품질은 결국 Transforme..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며RAG를 처음 붙였을 때 가장 쉽게 드는 생각은 이거다.“문서는 잘 검색되는데, 왜 답변은 여전히 애매할까?”Retriever도 튜닝했고, Ranker도 붙였고, 모델도 바꿔봤다.그런데도 답변 품질은 기대만큼 올라가지 않는다.이 지점에서 많은 사람이 LLM 성능을 의심한다. 하지만 실제로 문제의 원인은 대부분 Reader 단계, 정확히 말하면 프롬프트와 컨텍스트 구성에 있다. 이번 글에서는 RAG의 마지막 단계인 Reader를 단순한 “모델 호출”이 아니라 품질을 결정하는 최종 시스템 레이어로 바라보며, 프롬프트 설계와 Hallucination 문제를 어떻게 다뤄야 하는지 정리..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며 - Retriever 다음에 반드시 필요한 이유앞선 글에서 Retriever를 정리하였다. Retriever는 빠르지만, 정확하지는 않다.VectorDB 검색이든 BM25든, Retriever의 역할은 어디까지나 “후보군을 넓게 가져오는 것”이다. 보통 구조는 다음과 같다.Retriever: 관련 있어 보이는 문서 Top-50 ~ 100Ranker: 그중에서 정말 중요한 문서 Top-5 ~ 10이 두 단계를 분리하지 않으면 속도와 정확도를 동시에 만족시키기 어렵다.이번 글에서는 왜 Ranker가 필요한지, 그리고 Cross-Encoder 기반 Reranking이 왜 사실상 표준..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며“LLM이 똑똑하면 답변도 좋아지겠지.”하지만 실제로 RAG를 운영해보면, 품질 문제의 원인은 거의 항상 같은 지점에서 시작된다.Retriever가 잘못된 문서를 가져온다. 아무리 좋은 LLM을 써도, 아무리 프롬프트를 다듬어도, 입력 컨텍스트가 틀리면 결과는 틀릴 수밖에 없다.RAG에서도 결국 이 원칙이 그대로 적용된다. Garbage In, Garbage Out이번 글에서는 RAG 파이프라인의 첫 단계인 Retriever를 중심으로,Dense 검색Sparse 검색Hybrid 검색이 세 가지 방식이 왜 등장했고, 실무에서는 왜 Hybrid가 사실상 기본이 되었는지를 정리해본다..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며RAG(Retrieval-Augmented Generation)를 처음 접했을 때는 구조가 단순해 보인다.질문을 받고 → 문서를 찾고 → LLM에게 넘긴다.그래서 자연스럽게 이렇게 생각하게 된다. “LLM만 잘 고르고, 임베딩만 잘 쓰면 되는 거 아닐까?” 하지만 실제로 RAG를 붙여서 몇 번만 질의응답을 반복해보면금방 다른 감각을 얻게 된다.답변이 애매하다근거 문서가 엉뚱하다모델을 바꿔도 품질이 크게 나아지지 않는다이때 문제는 대부분 LLM이 아니다.RAG는 모델 기술이 아니라 아키텍처 문제에 가깝다.이번 글에서는 RAG를 기능이 아닌 시스템 파이프라인으로 바라보며,왜 구조 이해가..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며RAG를 처음 설계할 때는 자연스럽게 LLM과 Embedding에 시선이 간다.하지만 실제로 RAG를 붙여서 질의응답을 반복해보면,어느 순간 이런 느낌을 받게 된다.“모델은 괜찮은데, 답변이 뭔가 애매하다” 이때 많은 경우 문제는 LLM이 아니다.VectorDB 설정, 더 정확히 말하면 검색 튜닝에 있다. 이번 글에서는 RAG 파이프라인에서 VectorDB가 어떤 역할을 하고, 왜 튜닝이 성능을 좌우하는지, 그리고 어떤 기준으로 설정을 조정해야 하는지를 정리해보려 한다. ㅁ RAG에서 VectorDB가 병목이 되는 이유RAG의 흐름을 단순화하면 다음과 같다.질문 → 임베딩 →..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며앞선 글에서 Embedding, Vector Similarity, HNSW까지 정리했다면,이제 실제 VectorDB를 어떻게 쓰는지가 남는다.이번 글에서는 Weaviate를 기준으로,스키마 설계데이터 삽입 흐름벡터 검색하이브리드 검색(BM25 + Vector)을 정리한다. 중요한 점은 이것이다. Weaviate는 단순한 벡터 저장소가 아니라, “의미 기반 데이터 모델링 + 검색 엔진” 에 가깝다. ㅁ 왜 Weaviate인가VectorDB는 많다.Qdrant, Milvus, Pinecone 등 선택지는 충분하다.일전에 [AI] RAG구성을 위한 FAISS란?에서 FAISS를 정리하..

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 ㅁ 들어가며ANN과 HNSW는 VectorDB를 활용한 RAG 구현의 “심장”이다. Embedding은 의미를 벡터로 바꿔주고, Vector Similarity는 거리를 계산해 주지만, 수백만 개 벡터 중에서 실제로 무엇을 얼마나 빨리 찾을 수 있느냐는결국 ANN 인덱스가 결정한다. 그 중심에 있는 알고리즘이 바로 HNSW다.이번 글에서는 다음 흐름으로 정리해 보려 한다.ANN이 무엇인지왜 Brute-force 검색이 불가능한지HNSW가 어떻게 문제를 해결하는지그리고 실무에서 중요한 파라미터(M, ef)를 어떻게 바라봐야 하는지 ㅁ ANN이란 무엇인가ANN은 Approximate Neare..