오래된 SW 엔지니어의 평생 공부

[1]에서는 [2]에서 소개한 LLM Application의 Architecture를 위한 추상화 모델을 소개했다. [2]에서는 LLM 앱을 직접 구축하는 다섯 단계를 소개하고 있다. 그 내용을 살펴 보자.

• 문제에 집중: 처음에는 하나의 문제에 집중한다. 문제는 충분히 구체적이어서 빠르게 반복하고 진행할 수 있지만, 사용자를 감탄하게 할 정도로 충분히 큰 문제여야 한다.
• 올바른 LLM 선택: 특정 과제에 맞게 사전 훈련된 LLM을 선택한다. 상업적 사용이 가능한 라이센스가 있는 모델을 사용해야 할 수도 있다.
• LLM 맞춤화: LLM을 특정 작업에 맞게 조정하기 위해 인컨텍스트 학습, 인간 피드백에서의 강화학습(RLHF), 미세조정 등의 기술을 사용할 수 있다.
• 앱 아키텍처 설정: 사용자 입력, 입력 풍부화 및 프롬프트 구성 도구, 효율적이고 책임 있는 AI 도구 등 필요한 구성 요소를 설정한다.
• 온라인 평가 실시: 앱의 성능을 평가하여 사용자와의 상호작용 중에 모델의 출력 품질을 평가한다. 또한, 다양한 도구를 활용하여 사용자의 요구에 맞는 적절한 반응을 생성할 수 있도록 LLM을 최적화하고, 실시간 사용자 피드백을 통해 앱을 지속적으로 개선한다.

참고 문헌

[1] "Large Language Model의 추상화", https://technical-leader.tistory.com/127

[2] Nicole Choi, "The architecture of today’s LLM applications", https://github.blog/2023-10-30-the-architecture-of-todays-llm-applications/?fbclid=IwAR2daV0oLZAU8ZS45SeL5Wh7aVDcscJBL1hsEBBRVXW2rywoeqd6AnfwzJg

[1]에서도 다루었지만, 미리 트레이닝을 해야 하는 Machine Learning의 한 종류인 LLM도 동일한 특징을 가지고 있다. ChatGPT4o의 경우도  현재  23년 10월까지 업데이트 되어 있다고 한다. 이 부분의 한계를 극복하기 위한 것이 Retrieval Augmented Generation (RAG)이다. 이 부분은 추가된 정보를 제공해서 이를 기반으로 동작하게 하는 것이다. 이 동작을 이해하기 위한 몇 가지 개념이 있는데 임베딩 모델(Embedding Model), 벡터 데이터베이스(Vector Database)와 같은 개념이 있다. 이 부분에 대해서는 간단하게 다뤄 보자.

RAG(Retrieval-Augmented Generation)는 앞에서 언급한 Foundation Model이 최신 데이터를 가지고 학습하지 못한 문제를 해결하기 위한 방법 중 하나로,  LLM에 정보 검색을 결합하는 방식 또는 프로세스를 말한다. 즉, 검색된 정보를 이용해서 최신 정보와 원하는 정보를 추가하여 생성하도록 해서 신뢰성과 지식의 범위를 확장할 수 있도록 하게 한다.

이렇게 RAG를 하기 위해서 데이터를 추가 한다고 할 때, 추가된 데이터와 기존의 정보가 어떻게 관련되어 연관성이 있는지 알 수 있을까? 이를 이해하기 위해서 필요한 것이 임베딩 모델이다. 임베딩 모델은 정보를 다차원 공간의 조밀한 표현으로 캡슐화하도록 훈련된 알고리즘이다[2]. 좀 더 자세한 내용은 YouTube를 함께 보는 것도 좋다. 여기서 시각화 한 것과 같이 유사도를 vector측면에 cosine similarity를 사용하는지도 알 수 있다. 그리고, L2 distance 혹은 vector product도 사용할 수 있음도 알 수 있다. 이러한 것을 활용하여 시멘틱 서치(semantic search)가 가능해 진다.

이러한 정보를 어떻게 보관하고 사용할 것인가? 이를 위한 데이터베이스가 벡터 데이터베이스(vector database)이다[3]. 기존 데이터베이스도 위와 같은 임베딩을 저장하고 sementic search를 할 수 있지만, 저장된 모든 데이터의 embedding과 query embedding의 similarity를 연산해야 하기 때문에 너무 많은 연산을 해야 하고 느리게 결과를 가져오게 된다. 벡터 데이터 베이스는 자체적인 알고리즘으로 indexing하고 유사도 알고리즘을 조합하여 빠른 검색을 지원하므로 LLM에 RAG를 위해서는 이러한 데이터 베이스를 활용해야 한다.

결론은 [1]에서도 언급한 것처럼 LLM에 RAG이 적용되어야만 약점을 보완한 현대적인 아키텍처를 가진다고 볼 수 있다. 이 구조에는 임베딩 모델, 벡터 데이터 베이스들이 왜 연계되어 사용되는지, 그리고 왜 cosine similarity가 사용되는지 간단한  개념들이 살펴 볼 수 있다. 

참고문서

[1] Large Language Model의 추상화 , https://technical-leader.tistory.com/127

[2] 텍스트용 Vertex AI 임베딩: 간편해진 LLM 그라운딩, https://cloud.google.com/blog/ko/products/ai-machine-learning/how-to-use-grounding-for-your-llms-with-text-embeddings

[3] Vector Database: 벡터 임베딩을 저장하고 검색하는 가장 효율적인 방법, https://smilegate.ai/en/2023/11/07/vector-database-%EB%B2%A1%ED%84%B0-%EC%9E%84%EB%B2%A0%EB%94%A9%EC%9D%84-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B3%A0-%EA%B2%80%EC%83%89%ED%95%98%EB%8A%94-%EA%B0%80%EC%9E%A5-%ED%9A%A8%EC%9C%A8%EC%A0%81

[1] 의  3장 초기 접근 방법에 다음과 같은 리엔지니어링 프로젝트 예제를 이용해서 실제 예시로 패턴에 대해 설명한다.

• 시나리오: 사용자 팀은 의료 소프트웨어 시스템인 proDoc을 개발하고 있으며, 경쟁사인 XDoctor의 인터넷 기능을 proDoc에 통합하려고 합니다.
• 주요 과제: 시스템을 통합하고 리엔지니어링하기 위해 첫 번째 평가와 계획을 수립하는 것입니다.

주요 요구사항

1. 규모 문제: 레거시 시스템이 크고 복잡하므로 이를 관리 가능한 부분으로 나누어야 한다.
2. 시간 부족: 프로젝트 초기에는 시간을 낭비하지 않도록 주의해야 한다.
3. 불완전한 지식: 초기에 중요한 결정을 내릴 때 불완전한 지식으로 인해 잘못된 결정을 내릴 수 있다.
4. 다양한 이해관계: 여러 이해관계자들이 서로 다른 의제를 가지고 있을 수 있다.

패턴 적용:

• 유지보수자와의 담소나누기: 시스템의 역사적, 정치적 맥락을 이해하기 위해 유지보수자와 논의한다.
• 한 시간 안에 모든 코드 읽기: 소프트웨어 시스템의 상태를 빠르게 평가하기 위해 집중적으로 코드를 검토한다.
• 모의 설치 수행하기: 리엔지니어링 적합성을 평가하기 위해 시스템을 실제로 설치하고 실행해 본다.
• 문서 스키밍하기: 관련 문서를 빠르게 검토하여 중요한 정보를 파악한다.
• 데모 중 인터뷰하기: 시스템을 사용하는 사람들과 인터뷰를 통해 추가 정보를 수집한다.

예시

예시에서는 앞에서 설명한 것의 사례에서 일어 났던 경험을 해당 패턴에 연계하여 이야기 한다.

• XDoctor 인수: XDoctor의 개발팀에서 유일하게 남은 데이브와의 대화를 통해 중요한 기술적 정보를 얻고, 두 시스템을 통합하는 계획을 세훈다.
• 코드 검토: Java와 C로 작성된 코드를 검토하여 시스템의 구조와 품질을 평가한다.

결론

리엔지니어링 프로젝트를 성공적으로 수행하기 위해서는 초기 단계에서 정확한 평가와 계획이 중요하며, 이를 위해 다양한 패턴을 적용하여 시스템의 상태와 문제를 파악해야 한다고 이야기한다. 이 패턴들을 읽어 보면, 실재로 경험한 듯한 것들이 많다. 특히, 유지보수자와 담소나누기, 모의 설치하기 등은 마치 내 경험을 몰래 들여다 본 것 같은 느낌도 들 정도였다. 다른 것들의 경우도, 일부는 경험한 듯 하고 시간 제약을 두고 하는 것도 눈에 띄는 이야기였다. 무엇보다도 사회적 맥락에서 접근하는 패턴은 이 부분이 매우 실용적인 것이라는 생각도 많이 들었다. [2]에 번역 내용이 올라가 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP