Langchain은 사실 실제 서비스에는 적합하지 않습니다. 그 이유는요.. (랭체인 DIY의 한계 정리, RAG 챗봇 개발 유의점)

회사에서 RAG 구현을 고민하고 있나요? Langchain을 실제 서비스 개발에 도입을 고려하시나요? 그렇다면 이 글을 꼭 보시기 바랍니다. Langchain은 실제 서비스에 사용하기에는 적합하지 않기 때문입니다. 그 이유는 다음과 같습니다.

 

이번 주에 아래의 이메일을 받았습니다.

우리 기관에서 비슷한 솔루션을 구축하고 있었습니다, 현재 우리는 초점을 다른 곳으로 옮겨 정착된 제공업체를 우리 고객에게 추천하고 있습니다. 제가 연구해본 맞춤형 채팅봇 SaaS 중에서 당신의 서비스가 최고의 파트너가 될 것이라고 생각합니다.

이 기관은 상당한 개발 자원을 보유한 기술력이 상당한 기관입니다. 사실 책임자들은 수천명의 팔로워를 보유한 기술 관련 팟캐스트를 운영하기도 합니다.

왜 그들이 Langchain으로  RAG를 직접 개발하는 "Do It Yourself" 접근법을 포기했을까요?

 

짧은 버전의 답변

지하실에서 서버를 운영하지 않는 것과 같은 이유로 (대신 Amazon AWS를 사용하겠죠!), 마찬가지로 자체 RAG(검색 증강 생성) 시스템을 구축하고 운영하려고 하면 생산과 관련된 모든 문제를 다루어야 하는 책임이 생깁니다.

 

Langchain의 문제점들

그와 전화 통화를 하자마자 문제가 무엇인지 명확해졌습니다. 시작해보겠습니다. :

 

 

허구 생성

허구 생성을 처리하려면 RAG 파이프라인의 모든 단계에서 반-허구 조치를 시행해야 합니다. 허구 생성은 "프롬프트에 이것을 추가하라"와 같은 간단한 것이 아닙니다.

데이터 수집에서 최종 응답에 이르기까지 RAG 파이프라인의 모든 설계 결정에 "이것이 허구 생성에 어떤 영향을 미치는가?"라고 질문해야 합니다.

허구 생성만으로도 우리 시스템에서 수천시간의 엔지니어링 노력이 소요됩니다(왜 그런지 보기).

데이터 수집 문제

두 번째 큰 문제는 데이터 수집입니다. 이론적으로 PDF 파일을 수집하는 것이 간단해 보이지만, 실제로 수천 개의 문서와 웹 페이지를 가져오면 문제가 발생합니다. 각 문서에 대한 명확한 감사 기록이 있나요? 파이프라인이 오류에 탄력적인가요? 문서를 새로고침하거나 다시 처리하는 방법이 있나요?

미디어의 주목을 받는 AI와 달리, 실제 RAG 파이프라인을 운영할 때 데이터 수집이 실제 킬러입니다. 엔지니어링 시간의 약 40%가 데이터 수집에 소요되는 이유가 있습니다. 각 데이터 형식과 소스에는 복잡성이 있기 때문입니다.

예를 들어 YouTube 동영상을 수집해 보세요. 곧 그것이 악몽이란걸 알게 될 것입니다.

Langchain에 다섯 가지 PDF 파서가 있는 이유가 있습니다. 누구도 어떤 것을 사용해야 하고 어떤 조건에서 사용해야 하는지 모릅니다. 이러한 설계 결정은 오롯이 개발자의 몫입니다. 모든 것이 작동하기를 간절히 기도하길 바랍니다.

 

인용문 / 출처

Langchain의 좋은 점은 매우 짧은 시간 내에 프로토타입을 만들어 결과를 보여줄 수 있다는 것입니다. 좋죠!

그러나 보스나 CEO에게 데모를 하려고 하면 첫째 질문은 "그 응답이 어디서 나왔나요?" 또는 "그 응답이 어떻게 계산되었나요?" 또는 (더 나쁜 경우!) "잠깐, 그것은 전혀 의미가 없는데요!"

해결책: 응답에 대한 명확한 인용문과 출처 표시. Langchain은 이것을 위해 빌드하지 않습니다. 응답에 대한 투명성과 신뢰도를 보여주기 위해 스스로 인용 알고리즘을 구축해야 합니다.

질의 관련 문제

대부분의 RAG 파이프라인 교육 자료는 "행복한 경우"를 다루지만, 실제로 사용자는 쿼리하는 방법을 모릅니다.그들은 "음, 알겠어요", "그래, 더 말해줘", "2", "예", "그거", "알겠어요, 그래요" 등의 질의를 입력합니다.

의도를 명확하게 이해하는 프로세스를 구축하지 않는 한, 일반 사용자는 실제 인간과 라이브 채팅할 때와 마찬가지로 챗봇과 대화할 것입니다. 우리는 우리 봇에서 이를 직접 확인했습니다.

더 나쁜 상황: 일부 사용자는 대화하는 법을 전혀 모릅니다. 그들의 마음이 명확한 요구에도 불구하고 막힙니다. 당신의 봇이 어떻게 사용자를 참여시키고 만족을 이끌어 내는지 방법을 알까요? 

유지보수와 MLOps

이 부분은 대체로 간과되지만, OpenAI가 새로운 기능이나 새 모델을 출시할 때마다(예: 2022년 6월 13일 새 모델 출시함) RAG 파이프라인이 어떻게 영향을 받을까요??

예를 들어, 2022년 6월 13일 출시 후, 어떤 연유인지, 일부 고객의 경우 정상적인 영어 질의에 스페인어로 응답하기 시작했습니다.

이는 매우 짜증나는 문제였습니다. 왜냐하면 이유를 찾아내고 수정해야 했기때문입니다. (참고: system 메시지에서 사용한 단일 단어였음) 

하지만 이것이 유일한 것이 아닙니다. 속도 제한 문제나 API 다운타임 문제는 어떻게 처리 해야 하나요?

그리고 무엇보다도 최악은 고객이나 상사가 "왜 이 질문에 대한 봇의 응답이 이럴까요?" 라고 물을 거라는 것입니다!

규모의 경제

우리 모두 AWS와 같은 클라우드 플랫폼을 좋아하는 이유는 수백만 명의 고객에게 퍼지는 거대한 개발 비용 때문입니다. 그래서 실제 TCO 비용보다 훨씬 적은 비용으로 좋은 AWS 인스턴스를 얻습니다.

OpenAI API의 경우도 마찬가지입니다. OpenAI는 수백만 달러를 들여 LLM을 구축했고 이제 우리 모두 사용 기반 요금 $1(또는 그 이하)로 사용할 수 있습니다.

"Build It Yourself"를 선택하면 개발 비용이 "1로 나누어집니다".

OpenAI가 LLM의 문제를 수정하면 우리 모두 혜택을 볼 수 있습니다. 자체 개발한 RAG 파이프라인에 문제가 있으면 전체 개발 비용을 혼자 부담해야 합니다.

이것이 Langchain을 실제 서비스에 사용하는 것이 너무 비싸다는 이유입니다. 모든 사소한 문제를 디버깅해야 하는 것은 바로 당신과 당신의 팀입니다!

예를 들어, Youtube 동영상 수집 파이프라인을 수정하는 데 수백 시간의 엔지니어링을 투자했습니다. 이제 우리의 수천 명의 고객 모두가 이 이점을 얻습니다. - 수천 수만 달러가 아닌 동전 몇개로요.

보안

Langchain의 장점 중 하나는 문서의 데이터 보안을 제어할 수 있다는 것입니다. 따라서 자체 VPC나 온-프레미스 인프라 내에서 Langchain을 실행할 수 있습니다. 그건 확실히 훌륭합니다.

그러나, 보안에는 3가지 측면이 있으며 이 모두를 고려해야 합니다. 특히 다음과 같습니다.

1. 데이터 보안: 문서 및 리소스의 수집 및 후속 삭제. 또한 필요한 경우 PII* 제거 및 익명화를 구현해야 합니다. 너무 어렵지는 않지만 구축해야 합니다. 

2. 채팅 보안: 신뢰할 수 없는 사용자가 챗봇을 사용하는 경우 채팅 보안을 구축했습니까? 특히 NSFW* 쿼리나 탈옥 시도에 대비되었나요? 

3. 채팅 액세스 보안: 이제 채팅봇을 구축했으니, 누가 액세스할 수 있습니까? SSO*를 구축했나요? 또는 Teams 액세스 기능? 누가 액세스하고 그것이 기록되고 감사되고 있나요? 전체 액세스 제어 시스템을 구축할 건가요? 

 

지식 한입

- PII 의미 : Personal Identifiable Information, (개인 식별 정보) 개인을 식별할 수 있는 정보
- NSFW 의미 : Not Safe For Work, 후방주의라는 말로 LLM에 특정 쿼리를 넣어 탈옥시키는 이슈가 있음.
- SSO 의미 : Single Sign-On, 1회 사용자 인증으로 다수의 애플리케이션 및 웹사이트에 대한 사용자 로그인을 허용하는 인증 솔루션.

 

 

감사 및 분석(Audits & Anlytics)

오늘 날 Gen AI의 배포에 막힘이 되고 있는 최대 장애물은 AI 시스템에 대한 전반적인 감시와 검증이 어렵다는 점에 있습니다. 특히 최고정보보안책임자(CISO)들은 AI의 오류 위험성을 우려하는 경향이 높습니다. 그들은 AI가 무슨 말을 하고 있는지 완벽히 추적하고 감사할 수 있는 기준과 지침의 부재를 문제 삼고 있습니다. 거기엔 엄청난 FUD 가 있습니다.  

* FUD 뜻 : Fear, Uncertainty, Doubt : 공포, 불확실, 의심:

이는 AI 시스템에 대한 사전/사후 보안점검을 어렵게 만들고 있습니다. 또한 정보유출 위험에도 노출되어 있어 보안상의 걸림돌이 되고 있는 것입니다. 따라서 AI 시스템 사용자가 책임질 수 있는 실질적인 감사 지표와 추적 시스템의 확보는 Gen AI 보급의 필수적인 전제 조건이라고 볼 수 있겠습니다.

또는 긍정적인 면에서는 채팅 로그에서 통찰력을 얻기 위해 대시보드와 분석을 구현할 계획이 있습니까? (특히 상사나 다른 이해 관계자가 "봇에서 무슨 일이 벌어지고 있는지 말씀해 주시겠어요?"라고 물을 때)

 

지속적인 개발

마지막으로 가장 중요한 것은 기술이 진보함에 따라 지속적인 유지관리와 계속적인 개발 책임자 문제입니다.

OpenAI(및 기타)는 거의 매주 새로운 기능을 출시하는 것 같습니다. 누가 최신 기능을 파악하고(또는 더 나쁜 경우, 서비스 종료) 솔루션이 배포된 후에 새로운 기능을 통합할까요?

 

 

결론

Langchain은 시작하기에 매우 좋고 훌륭한 교육 도구이지만, 실제 운영 상황에 맞게 설계되지 않았습니다.

서버를 직접 조립하기 위해 용산 전자상가에 가는 것처럼 '자체 RAG 파이프라인 구축'은 그것과 유사합니다. 재미있긴 하지만 실제 프로덕션 사용이 필요할 때 자체 RAG 시스템을 실행하는 것은 컴퓨터의 각 부품을 구매하고 직접 조립하려는 것과 같습니다.

그렇습니다. 우리는 수십 년 전에 그렇게 했었죠. 지금은 LG나 Apple에서 구매하기만 하죠.

원글의 글쓴이는 CustomGPT의 CEO로, 자체 콘텐츠로 RAG 채팅봇을 구축할 수 있는 노코드 클라우드 RAG 플랫폼 비지니스입니다. 이 블로그 게시물은 지난 8개월 동안 수천 명의 비즈니스 고객과 함께 한 경험을 기반으로 작성되었습니다.(ChatGPT API가 도입된 이후).

 

원문을 정성껏 번역했습니다. 원문이 궁금하시다면 링크로!

아래 글도 재밌으니 읽어보세요!

이제 인공지능이 PPT도 자동으로 다~작성해준답니다_Gamma App

챗GPT 1주년 축하해!! 기술 지형을 뒤흔든 변곡점! 무엇이 변했고, 우리 일자리는 무사한가?

나이트셰이드란? - 인공지능 vs 예술가, 예술가의 권리를 지키기 위한 진흙탕 싸움 (AI에게 일자리를 위협받는 디자이너, 예술가의 살 길?)

Object Detection 모델의 성능평가 방법 mAP(mean average precision) 쉽게 쉽게 알아보자

 

#LangchainNotReady #RAGchallenges #LLMpitfalls #ChatbotIssues #dataprocessing #ingestionproblems #hallucinations #transparency #custsupport #scalingissues #securityrisks #analytics #maintenance #Langchain 서비스도입 #AI솔루션비교 #RAG 파이프라인 문제점 #테크 인사이트 #인공지능 트렌드 #데이터 보안 중요성 #챗봇 개발도전 #OpenAI 업데이트 대응 #테크팟캐스트추천 #데이터 수집 전략 #AI 투명성강조 #클라우드플랫폼효율성 #인공지능 유지보수 #비즈니스기술솔루션 #AI시스템감사