Multi-Agent 관련 리소스 모음


Multi-Agent 관련 리소스

Agent 방향에 대한 의견들 (from reddit comment)

  • No easy way to really control termination. Letting the LLM decide to terminate with a string is a poor design. In my case, my termination is just that the LLM generates no more executable code blocks.

  • No easy way to control executable vs. non-executable code blocks. In my case, I just extended the class to have an executable attribute with another # execution: true

  • Control hallucinations: Crucial element (even for top LLMs like sonnet-3.5-new) is to find ways to catch hallucinations before they get bad. A key to success was to not let the LLM do more than 1 executable code per turn, else it tends to make up stuff.

  • Good prompt engineering: Being able to be clear about what the system prompt contains, and how each tool has good suggestions about what to do next with the output it generated.

  • Multi-agent is not better than just single agent with tools. It’s much worse usually, I don’t know why people are so excited about multi-agent. I think the tools paradigm is much better, where the tool might happen to be really an agent. But nominally better to build a tool that does more to offload what agent has to think about. Dynamic creation of tools (program synthesis) is future.

  • It’s better to allow the LLM freedom to code but give access to reliable tools. It’s ok if one uses function calling to access a finite set of tools (say ~30 or so, depending upon the model) as long as it has access to code and can call those same functions via code. But a pure function calling is very limiting to a general agent.

Rag-Agent

Agentic RAG: RAG 에이전트는 검색 도구(Retriever Tool)를 사용하는 에이전트

  • 스스로 검색 쿼리를 작성: 더 관련성 높은 문서를 찾기 위해 질문을 재구성.
  • 결과를 평가하고 재검색: 결과가 부족하면 재검색.

References




    Enjoy Reading This Article?

    Here are some more articles you might like to read next:

  • Deepseek-R1 모델
  • 학습할때 메모리가 터진다고? Cut Your Losses!
  • GRPO 대신 DAPO: RL 최적화로 LLM 추론 능력 끌어올리기
  • DeepSeek-V3 기술 요약
  • python accelerate 라이브러리 함수 조사기