본 포스팅은 다음 블로그 글을 참고하여 작성하였습니다.https://postgrespro.com/blog/pgsql/4261647 Indexes in PostgreSQL — 7 (GIN)We have already got acquainted with PostgreSQL indexing engine and the interface of access methods and discussed hash indexes , B-trees , as well as GiST and SP-GiST indexes. And this article will feature GIN index. GIN "Gin?.. Gin is, it seems, such an Ampostgrespro.com 개요GIN은 Generalized Inv..

개요https://growth-coder.tistory.com/328 [Node.js] HTTP POST로 SSE 구현하기 + nginx buffering 문제 해결개요저희 프로젝트는 LangChain을 활용하여 AI 응답을 반환하는 API를 만들어서 사용하고 있습니다. AI가 생성한 응답을 그대로 HTTP 응답으로 반환해주는 API입니다. 하지만 이러한 형태는 AI의 응답growth-coder.tistory.com이전 포스팅에서 스트리밍 기능을 통해 chunk 단위로 클라이언트에게 보내주는 기능을 구현했습니다. 사용성 향상을 위해 응답을 중간에 멈추는 기능을 개발하려고 합니다. 가장 쉬운 방법은 단순하게 클라이언트에서 응답을 멈추는 버튼을 클릭하면 출력을 멈추는 방법입니다. 하지만 이 방법은 LLM 응..

CREATE EXTENSION IF NOT EXISTS vector;개요postgres에 저장된 문서 정보를 조회하여 사용자의 질의를 처리하는 RAG 시스템을 문서 유사도 검색으로 구현했더니 질의에 존재하는 키워드들을 잘 가져오지 못 하는 문제가 발생했습니다. 예를 들어 사용자가 "모든 회의록의 내용을 요약해줘"라는 질의를 보내면 "회의록" 키워드가 포함된 문서들을 잘 가져오지 못 했습니다. 문서 유사도 검색으로는 한계를 느꼈고 키워드 기반 검색을 추가한 hybrid search를 구현하기로 결정했습니다. 이번 포스팅은 사용자의 자연어 질의를 분석하여 hybrid_search를 통해 필요한 문서를 조회하는 기능을 구현한 과정을 기록한 포스팅입니다.postgres 환경 설정저희 프로젝트는 확장성이 굉장히 ..

개요제가 진행하고 있는 프로젝트는 문서 시각화와 문서 실시간 동시 편집 기능을 제공하는 프로젝트입니다.  프로젝트를 진행하면서 문서가 많아질수록 원하는 문서를 찾기가 어려웠습니다. 또한 연관된 여러 개의 문서 정보를 확인하기 위해서 하나씩 클릭해서 문서 정보를 열람해야 하는 불편함이 있었습니다. 그래서 저희는 이 불편함을 해소하고자 LLM 기반 RAG 기능을 도입하기로 결정했습니다. 실제로 OpenAI API를 사용해서 문서를 벡터로 변환한 뒤 질문과 유사한 문서를 찾아서 LLM이 자연어를 생성하는 것까지 성공했으나 한 가지 문제점이 있었습니다. 바로 저희 프로젝트가 변경 사항이 많이 발생한다는 점이었습니다. 실시간 동시 편집을 지원하기 때문에 문서의 변경 사항이 많고 변경 사항이 발생할 때마다 새로운 ..

https://www.acmicpc.net/problem/1520 풀이굉장히 어려웠던 문제입니다. DFS와 메모이제이션 기법을 적절히 사용해야 하는 문제였습니다. 풀이를 생각하지 못 하고 검색을 통해 해결했습니다. 첫 번째는 완전 탐색을 떠올렸습니다. DFS와 백트래킹 기법을 사용해서 완전 탐색을 하면 갈 수 있는 길의 개수를 구할 수 있습니다. 하지만 N과 M의 최대 크기는 500이었고 최대 칸의 개수는 250,000이었기 때문에 시간 초과가 발생합니다. 두 번째는 DP를 떠올렸습니다. dp[x][y]를 "좌표 (x, y)까지 도착할 수 있는 경우의 수"라고 정의하면 문제를 해결할 수 있을 것 같았습니다. 그래서 (0, 0)부터 (n-1, m-1)까지 dp 값을 구하면 해결할 수 있을 것 같았는데 문제..

개요저희 프로젝트에서는 Nest 프레임워크를 사용 중이고 서버의 역할을 분리하기 위해 monorepo를 사용하여 여러 개의 workspace로 나누었습니다. API를 담당하는 backend 서버와 실시간 통신을 담당하는 websocket 서버가 독립적인 workspace로 존재하는 상황입니다.  이렇게 독립적인 workspace로 분리하고 나서 조금 불편한 점을 발견했습니다. 바로 중복되는 모듈이 존재한다는 점이었습니다. 역할이 분리되었기 때문에 대부분의 소스 코드가 독립적이지만 redis에 관련된 모듈의 경우 backend 서버와 websocket 서버가 동일하게 사용하고 있었습니다. 저희 프로젝트는 아래처럼 websocket에 들어오는 변경 사항들을 redis에 저장해두었다가 스케줄러로 주기적으로 데..