As I've always been

최근 RAG(Retrieval Augmented Generation)과 같은 반환 기반의 솔루션들이 많이 사용되면서 정보 반환의 중요성이 더 강조되어지고 있다. 물론 벡터 데이터베이스 등의 다른 솔루션을 사용해서 문제를 해결할 수도 있으나, 상황에 따라 상위 K개의 결과를 반환하는 알고리즘 및 기능을 직접 구현해야 하기도 할 것이다. FAISS나 ChromaDB도 좋은 툴이지만, 개인적으로는 torch.topk() 메소드를 사용하는 유사도 반환 방식 역시 알아둘 필요가 있다고 본다. 가장 큰 이유는, FAISS나 ChromaDB 등의 솔루션의 경우에는 상당한 양의 메모리를 소모한다. 더 빠른 결과의 반환을 위해 인덱싱을 하다보니 그만큼 많은 메모리를 사용하게 된다. 이는 다시 말해, 물리적 한계로 인해 ..

허깅페이스 Transformers를 통해 생성 모델을 사용하다보면 생성 결과 자료구조 내에 "past_key_values"라는 값이 있는 것을 확인할 수 있다. 이를 보면 아마 두가지 의문점이 들 것이다: 1) 왜 과거의 key, value 값들이 중요한가 2) 왜 query는 포함되지 않는가? 이에 대해서 자세히 알아보기 위해서는 Transformer Decoder의 Causal Masking Self Attention에 대해서 알아야 한다. 기본적으로, transformer는 모든 단어를 병렬적으로 처리하기 때문에 autoregressive 한 특성이 없다. 따라서, Causal Masking을 사용해서 목표하는 문장의 일부를 가려서 인위적으로 연속성을 학습하게 한다. Vanilla Transform..

효율적인 Inference 요약, 질의응답(Q&A), 검색 증강 생성 등 언어 작업에 효과적인 기술로 Transformer 아키텍처에 기반한 대규모 언어 모델(LLM)이 부상했다. 하지만 이러한 모델을 사용하려면 계산 비용이 매우 많이 들며, 주로 NVIDIA GPU와 같은 컴퓨팅 가속기를 통해 실행된다. LLM에 대한 입력과 출력은 토큰 시퀀스(예: 단어)로 표현됩니다. 긴 시퀀스(즉, 컨텍스트 창이 긴)를 처리할 수 있는 LLM을 훈련하거나 미세 조정하는 것은 활발히 발전하고 있는 분야이다. 대부분의 OSS LLM 기본 모델은 2K 컨텍스트 창으로 사전 학습된다. 문서 요약이나 컨텍스트 기반 질문 답변과 같이 점점 더 많은 사용 사례에서 LLM이 처리하는 시퀀스 길이는 수천에서 수만 개의 토큰으로 상..

Queue는 일반적으로 각 어플리케이션들이 가지는 Coupling을 끊어주는 역할을 한다. 프로듀서가 메시지를 보내서 Queue에 메시지를 저장하고, 이를 컨슈머가 가져가서 프로세싱 하는 방식이다. 위 그림은 일반적인 Queue 의 처리 과정이다. Producer 는 메시지를 생성하여 Queue로 메시지를 전송한다. Queue는 메시지를 일정 기간 가지고 있게 된다. Consumer 는 주기적으로 Queue를 Polling 하면서 신규 메시지가 있다면 가져가서 처리한다. 처리가 끝나면 Queue로 Ack 를 전송한다. (메시지 아이디에 해당하는 Ack를 받으면 Queue에서 메시지를 제거한다. ) 이렇게 프로듀서와 컨슈머를 Queue 라는 미들웨어로 분리하면, 각 시스템에 영향을 받지 않고 원하는 작업을..

도커는 리눅스 커널이 기본으로 제공하는 기본 cgroup 기술을 이용해 애플리케이션이 좀 더 적은 리소스를 사용하게 할 수 있다. 쿠버네티스도 이러한 기능을 활용해 각 파드에서 사용하는 리소스의 양을 제한할 수 있다. 메모리 리소스 제한 컨테이너 내에서 애플리케이션을 실행할 경우 얻을 수 있는 주요 이점 중 하나는 바로 리소스 사용률을 제한할 수 있다는 것이다. 따라서 여러 애플리케이션이 동일한 하드웨어에 공존할 수 있으며 공정한 사용을 보장해준다. 200MB의 메모리와 1GB의 스왑 공간으로 제한하려면 docker run 명령어와 함께 --memory 및 --memory-swap 플래그를 사용할 수 있다. docker run -d --name mycontainer --publish 8080:8080 \..

이미지 크기 최적화 대용량의 컨테이너 이미지를 사용하기 시작하면 몇 가지 문제에 직면하게 된다. 가장 먼저 기억해야 할 사항은 시스템의 하위 계층에서 제거된 파일이 실제 이미지에서 존재한다는 점이다. 다음 상황을 고려해보자. - A 계층 (이름이 BigFile인 대용량 파일 포함) - B 계층 (이름이 BigFile인 대용량 파일 제거) - C 계층 (B 계층을 기반으로 정적 바이너리 제거) 위와 같은 상황에서는 BigFile이 더 이상 컨테이너 이미지 내에 존재하지 않는다고 생각할 것이다. 결과적으로 이미지를 실행할 경우, 해당 파일에는 더 이상 접근이 불가능하다. 그러나 실제로는 A 계층에 여전히 위치하고 있다. 즉, 더 이상 접근이 불가능한 파일임에도 전체 컨테이너 이미지의 크기에는 영향을 미치는 ..

컨테이너 이미지는 컨테이너 기술을 다루는 거의 모든 사람이 처음 접하게 되는 기술이다. 컨테이너 이미지는 OS 컨테이너 내부에서 프로그램을 실행하는데 필요한 모든 파일을 캡슐화하는 바이너리 패키지다. 컨테이너를 처음 접하는 방식에 따라 로컬 파일 시스템에서 컨테이너 이미지를 빌드하거나 이미 구축돼 있는 컨테이너 레지스트리(container registry)로부터 이미지를 다운로드하기도 한다. 두 경우 모두 컴퓨터에 컨테이너 이미지가 있으면 해당 이미지를 실행해 OS 컨테이너 내부에서 실행되는 애플리케이션을 생성할 수 있다. 가장 유명하고 널리 사용되는 컨테이너 이미지 포맷을 도커 이미지 포맷이며, 이를 사용할 경우 도커 명령으로 컨테이너를 패키징, 배포, 실행할 수 있다. 도커 이미지 포맷은 도커 오픈소..

웹 어플리케이션을 개발하다보면 JS, CSS, HTML 등과 같은 정적 파일들이 변경되게 되는데, 웹브라우저 등에 의해 캐싱이 되는 등의 이유로 인해 변경사항이 바로 적용이 안되는 등의 애환이 있다. 물론, "ctrl + shift + r"을 통해 매번 브라우저 캐시를 무시하는 완전 refresh를 시키는 방법도 있지만, 개발을 하면서 매번 이러한 작업을 하는 것 자체가 매우 번거로운 일이다. 이러한 제약사항을 극복할 수 있는 방법을 찾던 중, 캐시 만료 설정인 "expires"에 -1을 넣으면 브라우저 캐싱을 막을 수 있다는 사실을 알게 되었다. upstream api_server { server 127.0.0.1:8080; keepalive 100; } server { listen 80; listen..

tl;dr joinedload를 사용하면 JOIN된 전체 attribute들을 select하나, Query.join()은 query의 대상이 되는 table의 항목들만 select의 대상이 된다. 이 글은 SQLAlchemy의 공식 문서를 번역한 것입니다. 원문: https://docs.sqlalchemy.org/en/14/orm/loading_relationships.html#sqlalchemy.orm.joinedload Joinedload는 Query.join()의 사용과 많은 유사점이 있기 때문에, 언제 어떻게 사용해야 하는지에 대해 혼동을 일으키는 경우가 많습니다. Query.join()은 쿼리 결과를 변경하는 데 사용되는 반면, joinedload()는 쿼리 결과를 변경하지 않고 렌더링된 조인의..

2019년 초 OpenTelemetry 프로젝트는 OpenTracing과 OpenCensus라는 두 프로젝트의 병합으로 탄생했다. 프로젝트의 초기 목표는 두 개의 프로젝트를 하나로 합치는 것이었지만 클라우드 네이티브 소프트웨어에 대한 관찰 가능성 프레임워크를 제공하겠다는 야심이 프로젝트를 큰 과제로 만들었다. OpenTelemetry는 기본적으로 OpenTracing과 OpenCensus의 개념을 결합한 것이기 때문에 우선은 이 둘을 잘 살펴볼 필요가 있다. OpenTracing 2016년에 시작된 OpenTracing 프로젝트는 사용자가 시스템을 더 잘 이해하기 위한 수단으로 분산 추적을 채택하는 비율이 증가하는 것에 따른 문제를 해결하는 데 집중했다. 사용자들은 분산 추적 도입으로 인해 발생하는 비용..