RAG은 생각보다 훨씬 간단합니다
RAG Is Simpler Than You Think
대부분의 RAG 시스템이 과도하게 설계되어 있습니다. 이 글은 BM25 기반의 단순한 전체 텍스트 검색부터 쿼리 재작성, 하이브리드 검색, 온더플라이 임베딩, 핫/콜드 티어, 전체 사전 임베딩까지 6가지 RAG 아키텍처를 소개합니다. 각 접근 방식의 장단점과 적합한 상황을 설명하며, 데이터 신선도, 코퍼스 특성, 쿼리 패턴, 규모, 팀 역량에 따라 선택해야 한다고 조언합니다. 특히 쿼리 재작성의 효율성과 임베딩 모델 교체의 비용을 강조하며, 대부분의 경우 복잡한 임베딩 없이도 문제를 해결할 수 있다고 주장합니다.
저는 팀들이 벡터 데이터베이스 최적화에 몇 달을 쓰는 것을 봤지만, 쿼리 재작성이 문제의 90%를 해결했을 것입니다.
HN 토론
203- usernametaken29
저는 이전에 대규모 RAG 시스템을 작업해봤는데, 사람들이 전문 검색(full text search)을 크게 과소평가하고 임베딩을 크게 과대평가한다고 말할 수 있습니다. FTS는 정말 쉽고, 이식성이 뛰어나며 확장 가능하고 아주 멀리 갈 수 있습니다. 80/20 법칙이 적용됩니다. 임베딩은 멋지고 마법처럼 보이지만 실제로 깊이 파고들면 알게 됩니다: 의미적 유사성은 생각만큼 좋지 않고, 확실히 모든 사람을 만족시키지 못할 것입니다. 결국 더 정확한 임베딩 검색을 수용하기 위해 텍스트의 더 많거나 다른 청크를 다시 임베딩해야 하는 상황이 불가피하게 발생합니다. 그 시점에서 마지막 단계로 가서 리랭킹 등을 하게 되고, 그 모든 동안 벡터 검색의 운영 부담을 지원해야 합니다. 그런 다음 돌아서서 500개의 키워드로 검색 쿼리를 만들면 확실히 고통스럽지만 그냥 작동하고, 모든 사용 사례를 수용하며, 확장되고, 전반적으로 유지보수가 덜 귀찮습니다.
- alansaber
저는 이러한 모든 접근 방식을 (모두 함께) 사용하여 시스템을 구축해봤습니다. 대부분의 경우, (고도로 최적화된 코퍼스 특화 정보 검색 전략을 구축하는 것은) 아주 드문 경우를 제외하고는 수고에 비해 얻는 것이 없습니다. 기술적 논의의 양이 RAG의 사용 사례를 훨씬 능가합니다.
- jillesvangurp
RAG는 기본적으로 LLM이 쿼리를 수행하는 좋은 옛 정보 검색입니다. 여기에는 벡터 검색이 포함될 수 있지만 그것 없이도 작동합니다. 벡터 검색을 노력 없이 검색을 훌륭하게 만드는 마법의 요정 가루로 취급하는 것은 반드시 잘 작동하지 않을 수 있습니다. 또한, 방정식에 많은 비용과 복잡성을 추가할 수 있습니다. 그리고 제대로 튜닝되지 않으면 반드시 좋은 결과를 얻는 것은 아닙니다. RAG의 핵심은 가능한 한 적은 쿼리로 올바른 정보를 컨텍스트에 넣는 것입니다. 이를 위해서는 좋은 재현율(거기에 있다면 합리적인 쿼리로 찾을 수 있도록 보장)과 정밀도(최고의 것이 맨 위에 오도록 하고 오탐을 최소화)가 필요합니다. 검색, 그리고 확장하여 RAG에서는 '쓰레기를 넣으면 쓰레기가 나온다'는 원칙이 적용됩니다. AI와 RAG 이전에 검색 팀이 했던 대부분의 일은 여전히 RAG 경험을 최적화하는 가장 좋은 방법입니다. 그리고 그것을 망치면 검색이 잘 작동하지 않을 것이며, 어떤 양의 AI도 그것을 보상할 수 없거나 엄청난 토큰과 시간 비용으로만 보상할 수 있습니다. 따라서 인덱싱할 것을 전처리하는 ETL 파이프라인을 갖는 것, 검색 품질을 테스트하고 벤치마킹하는 것 등은 모두 도움이 됩니다. 좋은 소식은 이 작업에 에이전틱 코딩에 대한 많은 기술이 필요하지 않다는 것입니다. 이 코드는 거의 스스로 작성됩니다. 그리고 인덱싱 전에 구조를 추출하는 데 약간의 노력만 해도 큰 차이를 만들 수 있습니다.
- jrochkind1
LLM에 관한 더 많은 LLM 생성 텍스트입니다. 다른 사람들도 LLM 생성 텍스트를 읽는 것이 점점 더 어렵다고 느끼나요? 저는 꽤 피곤하다고 느낍니다. 제 뇌가 그것을 끝까지 읽고 싶어하지 않습니다.
- Angostura
저는 첫 사용 시 약어를 풀어 쓰지 않는 게으른 기사에 대해 특별한 반감이 있습니다. 그래서: https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- yipinwong
자신의 작업을 단순해 보이게 만드는 것은 그 기술을 마스터한 사람들뿐입니다. 이것을 쓴 AI가 마스터일 수 있습니다. 작가가 아니라요. 이것은 AI가 쓴 것처럼 보이기 때문입니다. 저는 작가의 에이전트를 사용할 것이지, 그의 기사를 읽거나 그를 고용하지 않을 것입니다.
- refactor_master
여기 더 간단한 접근 방식이 있습니다: 처음에 모든 것을 임베딩한 다음 변경된 것을 추적하세요. 저렴한 모델을 사용하여 요약과 키워드로 문서/채팅을 정리하세요. 임베딩할 책 전체 라이브러리가 없다면 API 호출 비용은 수백 달러 정도일 것입니다. 그런 다음 모든 것을 BigQuery에 넣으세요. 벡터 관련 모든 것을 기본적으로 처리합니다. 그 위에 에이전틱 봇 UI를 뿌려서 모든 것을 알고 마법처럼 보이게 만드세요. Google 외의 다른 공급업체도 비슷한 배터리 포함 접근 방식을 제공하여 바로 연결할 수 있다고 가정합니다.
- klm127
RAG는 Retrieval Augmented Generation의 약자입니다. 목적은 정확한 일치보다는 의미로 텍스트 코퍼스를 검색하는 것입니다. 저는 그것을 찾아봐야 했습니다.