피터의 개발이야기

ㅁ 이 책을 읽게 된 이유이 책은 단순한 투자서가 아니라,환율·금리·채권·달러·금이라는 요소들이 어떻게 연결되어 움직이는지를‘돈의 흐름’이라는 하나의 구조로 설명한다.개별 자산의 전망을 맞히는 것이 아니라,위기와 성장 국면에서 자본이 어디로 이동하는지 판단하는 기준을 얻고자 읽었다.ㅁ 오건영은 누구인가?오건영은 예측하는 사람이 아니라 구조를 설명하는 사람이다특정 시점의 주가나 환율을 맞히는 데 관심이 없다왜 그런 방향으로 움직일 수밖에 없는지를 설명한다결과보다 과정과 연결 관계를 중시한다그는 시장을 단일 자산으로 보지 않는다환율, 금리, 채권, 주식, 달러, 금을 분리하지 않는다하나의 자산 변화는 다른 자산의 원인이자 결과가 된다항상 ‘자본 이동’이라는 공통 축으로 설명한다오건영의 설명은 정책과 시장을 ..

[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 시스템을 향해 ㅁ 들어가며Week 2에서는 Embedding부터 VectorDB까지, RAG 시스템의 검색 품질을 결정하는 핵심 요소들을 하나씩 정리해 왔다. 처음에는 단순히 “임베딩을 만들고, 벡터 검색을 하면 되겠지”라고 생각했다. 하지만 실제로 파고들어 보니 전혀 아니었다.Embedding → Chunking → Vector Similarity → ANN(HNSW) → VectorDB 구조와 튜닝 이 모든 요소가 하나의 검색 파이프라인으로 연결되어 있었고, 어느 하나라도 잘못 설계되면 RAG 품질은 바로 무너졌다. 이번 글에서는 그동안 쪼개서 정리했던 내용을 다시 묶어, Wee..

[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..