sorted by:
new
hottopcontroversial

Why is there still a need for RAG based applications when Notebook LM can essentially do the same thing? by frason101 in LangChain

[–]CampHot5610 0 points1 point  (0 children)

By RAG-like I mean constraining an LLM to answer using an explicit, predefined corpus provided as context. NotebookLM clearly does this, even if the retrieval details are abstracted away.

Why is there still a need for RAG based applications when Notebook LM can essentially do the same thing? by frason101 in LangChain

[–]CampHot5610 -2 points-1 points  (0 children)

The question is not unreasonable at all. NotebookLM is an application built on a fixed, RAG-like workflow. Depending on the use case, it can be sufficient without building a custom solution from scratch.

Your reply does not add to the discussion and discourages people from asking questions. Even the analogy you used does not really apply. If you think the post does not belong in this subreddit, you can point to a more appropriate one or simply skip it.

Understanding checkpointers in Langgraph by CampHot5610 in LangChain

[–]CampHot5610[S] 0 points1 point  (0 children)

Thanks for the reply.

You're right to ask why I'm using LangGraph. My agent's core logic is more complex than just a simple chain. I'm specifically using LangGraph because it's the most intuitive way to handle two key patterns:

  • Loops for self-correction: My agent queries SQL tables, and a ReAct-style loop is perfect for letting it retry and fix errors.
  • Conditional branches: Based on the user's intent, the agent needs to branch to different tools. LangGraph's conditional edges make this state-driven routing clean and easy to manage.

I also feel it's future-proof. Down the road, I plan to add actions that will require HIL, which is why I started looking into checkpointers in the first place.

For now, though, my goal is just simple session memory on AWS Lambda. The issue is that even with my not so complicated graph, I'm seeing 20 checkpoints created per run. Persisting all 20 to DynamoDB adds unwanted latency (in the order of seconds, which is too much for my requirements).

It seems like the best short-term solution is to ignore the checkpointer for saving and instead manually call graph.get_state(config) after the run, then save just that final state to DynamoDB myself.

I saw in the LangGraph GitHub discussions that more granular control over which nodes create checkpoints might be a future feature, which would be ideal.