Agentic RAG

사진: Unsplash 의 Shubham Dhage

이전글

2024.11.15 - [DEV] - AI Agent concept

AI Agent concept

2024.11.16 - [DEV] - AI agent frameworks

AI agent frameworks

 

Agentic RAG = 에이전트 기반 RAG

AI 분야에서 에이전트라는 말을 사용할 때, 명사(Agent)로 사용하기보다 형용사(Agentic)로 사용하는 더 유용하다고 제안 - 엔드류 응

특정 시스템이 에이전트냐, 에이전트가 아니냐라고 논쟁하기보다는 이 시스템의 에이전트적인 단계가 어느 정도인지 보자는 것 

https://www.deeplearning.ai/the-batch/issue-253/

Apple's Gen AI Strategy, Stability's Copyright-Clear Audio Generator, and more

reAct 기반 추론에 대한 비판

https://arxiv.org/abs/2405.13966

ReAct 기반 프롬프팅을 통해 생성된 추론 과정, 내용이 구조가 아니라 주로 입력 예제와 쿼리 간의 유사성에 의해 결정

기존 RAG의 문제점

RAG는 AI가 더 정확하고 최신의 답변을 제공하는데 도움이 되지만, 아직 완벽하지 않다.

너무 많은 데이터로 인한 어려움, 단 하나의 검색 단계만 수행 → 한 번의 검색결과가 나쁘면 추론결과도 나쁘다.

모든 데이터에서 무엇이 중요한지 쉽게 결정할 수 없다.

근본적으론 RAG만으로는 특정 질문의 최적의 답을 선택할 수 없는 것

단순히 많은 데이터를 추가하는 것만으로는 해답이 될수 없고, 정보를 이해하고 맥락화하는 더 똑똑한 방법이 필요함. 

사용자의 의도가 분명한 시나리오에서는 RAG로 충분, 원하는 답변이 검색된 결과에 포함되어 LLM에 한 번에 보낼 수 있는 경우.

그러나 대부분의 상황에서 모호한 사용자 의도가 일반적이며 최종 답변을 생성하기 위해 반복적인 쿼리가 필요.

Transformers Agent - huggingface

sample code for re-retrieve agent

agent를 통해 질의 변경, 필요한 경우 재검색

class RetrieverTool(Tool):
    name = "retriever"
    description = "Using semantic similarity, retrieves some documents from the knowledge base that have the closest embeddings to the input query."
                  #의미론적 유사성을 사용하여 지식 베이스에서 입력 쿼리에 가장 가까운 임베딩이 있는 일부 문서를 검색합니다.
    inputs = {
        "query": {
            "type": "text",
            "description": "The query to perform. This should be semantically close to your target documents. Use the affirmative form rather than a question.",
                            #수행할 쿼리입니다. 이는 의미상 대상 문서와 유사해야 합니다. 질문보다는 긍정형을 사용하세요.
        }
    }

https://colab.research.google.com/github/huggingface/cookbook/blob/main/notebooks/en/agent_rag.ipynb#scrollTo=U_FdfLJB7Z9Z

agent_rag.ipynb

Agentic RAG vs standard RAG

위 코드의 agentic RAG와 stardard RAG 정확도 평가 비교, 간단한 프롬프트 변경 agent로 정확도 향상

Average score for agentic RAG: 78.5%

Average score for standard RAG: 70.0%

 

LangGraph

LangGraph

 

LangGraph는 LangChain을 확장하여 LLM 애플리케이션에 대한 순환 계산 기능을 제공하는 라이브러리

LangChain은 계산 체인(Directed Acyclic Graphs 또는 DAG) 정의를 지원하는 반면,

LangGraph는 사이클을 통합, LLM을 루프에서 호출하여 다음에 수행할 작업을 결정할 수 있는 보다 복잡한 에이전트와 같은 동작이 가능

에이전트는 Langchain+ReAct개념을 사용하거나, LangGraph를 사용하여 구현가능 

신뢰성

• ReAct/Langchain Agent: LLM이 각 단계에서 올바른 결정을 내려야 하므로 신뢰성이 떨어짐
• LangGraph: 제어 흐름이 설정되고 LLM이 각 노드에서 수행할 특정 작업이 있으므로 더 안정적

 

유연성

• ReAct/Langchain Agent: LLM이 모든 작업 시퀀스를 선택할 수 있으므로 더 유연함
• LangGraph: 각 노드에서 제어 흐름을 설정하여 작업이 제한되므로 유연성이 떨어집니다.

 

소규모 LLM과의 호환성

• ReAct /Langchain Agent : 호환성이 떨어짐
• LangGraph : 더 나은 호환성

Agentic RAG example

agentState → Node and Edges → graph

검색된 문서의 품질 평가 후 품질 낮을 경우 쿼리 재작성 후 반복 검색

query re-write

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
 
#Edges
def grade_documents(state) -> Literal["generate", "rewrite"]:
...
if score == "yes":
        print("---DECISION: DOCS RELEVANT---")
        return "generate"
else:
        print("---DECISION: DOCS NOT RELEVANT---")
        print(score)
        return "rewrite"
 
### Nodes
def agent(state):
 
def rewrite(state):
 
def generate(state):
 
 
# Define a new graph
workflow.add_node("agent", agent)  # agent
retrieve = ToolNode([retriever_tool])
workflow.add_node("retrieve", retrieve)  # retrieval
workflow.add_node("rewrite", rewrite)  # Re-writing the question
workflow.add_node(
    "generate", generate
)  # Generating a response after we know the documents are relevant
# Call agent node to decide to retrieve or not
workflow.add_edge(START, "agent")
 
# Decide whether to retrieve
workflow.add_conditional_edges(
    "agent",
    # Assess agent decision
    tools_condition,
    {
        # Translate the condition outputs to nodes in our graph
        "tools": "retrieve",
        END: END,
    },
)
 
# Edges taken after the `action` node is called.
workflow.add_conditional_edges(
    "retrieve",
    # Assess agent decision
    grade_documents,
)
workflow.add_edge("generate", END)
workflow.add_edge("rewrite", "agent")
 
# Compile
graph = workflow.compile()
 
# display graph
display(Image(graph.get_graph(xray=True).draw_mermaid_png()))

 

display graph

벡터검색, 웹검색 수행여부 판단, 검색된 문서의 평가 후 할루시네이션 답변 정확도 판별

vector, web search

workflow = StateGraph(GraphState)
 
# Define the nodes
workflow.add_node("websearch", web_search)  # web search
workflow.add_node("retrieve", retrieve)  # retrieve
workflow.add_node("grade_documents", grade_documents)  # grade documents
workflow.add_node("generate", generate)  # generatae
 
 
# Build graph
workflow.add_conditional_edges(
    START,
    route_question,
    {
        "websearch": "websearch",
        "vectorstore": "retrieve",
    },
)
 
workflow.add_edge("retrieve", "grade_documents")
workflow.add_conditional_edges(
    "grade_documents",
    decide_to_generate,
    {
        "websearch": "websearch",
        "generate": "generate",
    },
)
workflow.add_edge("websearch", "generate")
workflow.add_conditional_edges(
    "generate",
    grade_generation_v_documents_and_question,
    {
        "not supported": "generate",
        "useful": END,
        "not useful": "websearch",
    },
)
 
 
# Compile
app = workflow.compile()

Agentic RAG + Graph RAG

routing 단계에서 vector, web, 검색외에 지식그래프에 대한 검색을 추가한다면 품질을 더 올릴 수 있지 않을까?

기업 내 RAG 도입의 실패 원인과 해결 방안

https://www.itworld.co.kr/news/347554

기업 내 RAG 도입의 실패 원인과 해결 방안 "검색 모델 최적화와 데이터 품질"

데이터 품질과 검색 모델의 최적화 부족

• RAG 시스템의 성패는 데이터의 정확성과 관련성, 그리고 검색 모델이 대규모 데이터에서 유의미한 정보를 효과적으로 필터링해 LLM(대형 언어 모델)에 제공할 수 있는 능력

적절한 컨텍스트를 제공하는 데 실패

• 사용자가 질문할 때 제공하는 컨텍스트에 크게 의존하는데, 이 컨텍스트가 불충분하거나 잘못되면 시스템이 부정확하거나 관련 없는 응답을 생성
• 특히 다중 주제나 복잡한 쿼리에 직면했을 때 더욱 두드러짐

RAG 시스템이 다중 주제 영역을 효과적으로 처리하지 못하는 경우

• 많은 주제를 다루게 되면 혼란이 생길 수 있으며, 이로 인해 정확도가 떨어질 수 있음
• MRKL(모듈식 추론, 지식, 언어) 접근 방식을 사용하는 것이 권장되며, 이를 통해 각 주제에 맞는 AI 에이전트를 선택하여 더 정확한 응답을 제공

고려할 점

• LLM 기반 에이전트는 LLM의 생성 능력에 크게 의존
• 오픈소스 소규모 LLM(3B, 7B)은 프롬프트를 효과적으로 이해하는 데 어려움
• 유능한 에이전트를 구현하려면 GPT-4와 같은 성능이 더 높은 LLM을 권장
• 컨텍스트 윈도우의 제한, 에이전트가 더 복잡한 문제를 해결하는 능력이 제한
• 레이턴시 → 최적화 필요

openAI o1 & CoT

https://openai.com/o1/

openAI o1 모델은 CoT 방식으로 학습됨

깊은 추론을 요구하고 더 긴 응답 시간을 수용할 수 있는 애플리케이션을 개발하는 경우 o1 모델이 훌륭한 선택

문제 해결에 필요한 추론량에 따라 요청 처리에 몇 초에서 몇 분까지 걸릴 수 있지만 답을 주지 못할 때도 있음

42(은하수를 여행하는 히치하이커를 위한 안내서)

42(은하수를 여행하는 히치하이커를 위한 안내서)

 

o1 model 성능비교

검색기능사, 프롬프트 엔지니어링

검색서비스가 처음 생겨났을 때 검색기능사 같은 자격증 시험도 있었지만 최근에는 관심이 없는 듯

이유를 생각해 보면 사람들의 검색/인터넷에 대한 이해도가 높아진 것도 있지만, 검색의 품질이 좋아졌기 때문으로 보임

마찬가지로 지금 우리는 CoT, reAct와 같은 프롬프트 엔지니어링을 이야기하고 있지만, 앞으로 모델의 품질이 좋아지면서 프롬프트 엔지니어링도 자연스럽게 사라질 수도 있을 것 같다.