[HN Gopher] LangGraph Engineer
       ___________________________________________________________________
        
       LangGraph Engineer
        
       Author : gfortaine
       Score  : 49 points
       Date   : 2024-08-09 16:28 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | peab wrote:
       | I don't really understand why an engineer would use langraph. If
       | a graph based interface for coding was useful, wouldn't they
       | already be used for regular programming? Regular software
       | functions can be viewed as graphs already, what's new about LLMs
       | that make a graph based UI desired? Maybe for really basic no-
       | code programs for non-programmers?
        
         | nfcampos wrote:
         | Langgraph is not a no-code tool for visual programming, it's an
         | implementation of the Pregel algorithm for execution of
         | cyclical computation graphs (ie not DAGs)
        
           | esafak wrote:
           | What's your opinion of Langgraph, if you're not affiliated
           | with it?
        
             | nfcampos wrote:
             | I'm one of the authors so my opinion would be biased ha
        
           | krawczstef wrote:
           | Really? Can you point to code for that? To me it's just a way
           | to describe a graph and execute it, exactly like
           | https://github.com/dagworks-inc/burr (I'm an author).
        
             | esafak wrote:
             | https://github.com/langchain-
             | ai/langgraph/tree/main/libs/lan...
        
           | peab wrote:
           | Oh I see - that's interesting.
           | 
           | Honestly I'm happy to be proven wrong about the usefulness of
           | it.
           | 
           | I've used langsmith and found it quite useful. I think I was
           | just so jaded by my bad experience with Langchain, that I'm
           | immediately skeptical of other "lang" products.
        
             | sbrother wrote:
             | I almost didn't try langgraph because I had similar
             | experiences with langchain. IMO it is a lot better than
             | langchain; its abstractions are lower level and more
             | appropriate at least for the projects I've taken on. I
             | think it's probably the best toolkit with which to
             | prototype an agent-based workflow right now.
             | 
             | That being said, it's not doing that much. And you still
             | end up having to use some of langchain's abstractions. If
             | this current "make a cyclical graph of LLM agents that send
             | messages to each other" thing has any staying power than I
             | imagine we'll see a more robust option soon. Personally I'd
             | love a way to build agent graphs in a strongly typed
             | language with first class concurrency.
        
         | swyx wrote:
         | i recently learned that superhuman uses langgraph fwiw
         | https://www.youtube.com/watch?v=Pt3xdZ5vcxE
        
         | fsndz wrote:
         | all that could be implemented simply using instructor:
         | https://www.lycee.ai/courses/a1ba236b-59e8-48e3-8577-a3e7bc6...
        
           | peab wrote:
           | I had built out a few util functions for llms using pydantil
           | that I used all the time until I found instructor - it's so
           | simple but so so useful
        
         | aaronvg wrote:
         | One of the issues with LLMs is that each function needs to be
         | tested and observed more thoroughly than regular functions,
         | which leads to these UIs to figure out what the heck is
         | actually going on.
         | 
         | For our DSL (BAML https://github.com/BoundaryML/baml ) we found
         | that adding a VSCode playground to visualize LLM function
         | inputs and outputs was a massive win in terms of debuggability
         | and testability, so I can see why langraph is going this way.
        
       | montebicyclelo wrote:
       | The core concept of agent graphs seems quite similar to an LLM
       | agent framework I created last year, [1].
       | 
       | Imo it is a more promising way to make agents, than the prior
       | approach of just giving an LLM N tools to use at once.
       | 
       | [1] https://github.com/sradc/MakeAgents
        
       | refulgentis wrote:
       | I don't understand how LangChain is in enough of an echo chamber
       | that I'm reading RTs this AM from the titular lead cheering on
       | someone open-sourcing "AGI" via the umpteenth implementation on
       | LangChain of "monkeys on typewriters via N LLM responses"
       | 
       | I don't complain actively about LangChain because this seems
       | widely understood at this point, and apologize for being abrupt,
       | but at some point, when this behavior is repeated, the assumption
       | shifts from "lack of perspective on our own work", which we all
       | suffer from, into "feigned naivete designed to mislead"
        
       | dbmikus wrote:
       | I was thinking through, what are the benefits of coding up your
       | agent system via a pregel-like graph, instead of just doing
       | function calls? Or versus the actor model? The execution trace of
       | a (concurrent or serial) computer program is a graph. And the
       | actor model lets you do message passing between "nodes/actors"
       | without having to predeclare your graph structure.
       | 
       | The three reasons I can think of:                   1. by
       | predeclaring the structure, you can show debugging UI of the full
       | graph, even if you've only executed part of it         2. Pregel
       | can make it easier to reason about global state transitions (you
       | can accomplish this in other systems too, if you set it up right)
       | 3. by enforcing heavier structure on your program, you can ask
       | the AI to reason about the whole graph or generate new graph
       | parts
       | 
       | The downside is that this is an abnormal way of writing computer
       | programs, originally designed for high-scale processing (Hadoop,
       | Apache Spark, etc.). If you want to dynamically change the
       | control flow of your program or special case control flow at
       | various points, you'll wrestle against the up-front graph
       | structure.
       | 
       | I personally have more of a preference to write normal-looking
       | code, without having to predeclare my execution graph.
        
         | huevosabio wrote:
         | Yes, I originally thouoof building AI workflows with an
         | existing DAG package or creating my own.
         | 
         | But I think DAGs don't scale, or rather, as you point out, it
         | quickly becomes easier to reason about code than about a graph.
         | 
         | I thought, maybe a setup like pytorch that let's you code it
         | normally and once you run it or compile it creates a graph for
         | you to see. But I remain unconvinced.
        
           | dbmikus wrote:
           | I've thought about the same things as we built our own open
           | source project for LLM workflows
           | (https://github.com/gofixpoint/fixpoint/).[1]
           | 
           | I like the Pytorch comparison, and I've seen DSPy position
           | themselves as Pytorch for prompting.
           | 
           | I also think the actor model is a natural fit for AI agents,
           | which has some similarities with Pregel (message passing),
           | and some differences (there are no super-steps of graph
           | execution, each actor has its own thread).
           | 
           | I definitely dislike state machines for most use cases.[2] I
           | think we can learn a lot about good AI agent paradigms from
           | game programming, and I enjoyed this article on game state:
           | https://gameprogrammingpatterns.com/state.html
           | 
           | At the end, they mention that game AI doesn't often use state
           | machines anymore, because the structure they impose is
           | limiting.
           | 
           | Also, the folks behind Temporal are anti-state-machine:
           | 
           | https://pages.temporal.io/download-state-machines-
           | simplified...
           | 
           | https://community.temporal.io/t/workflow-maintainability-
           | abs...                   [1]: our goal is to be an open-
           | source alternative to the OpenAI Assistants API, not to
           | compete with LangGraph, but there is overlap         [2]: I
           | understand that LangGraph is not a state machine
        
         | nfcampos wrote:
         | Pregel actually doesn't require the structure of the graph to
         | be declared ahead of time, the next set of tasks (functions) to
         | run is computed at the beginning of each step, so in theory the
         | graph topology could be entirely dynamic. Langgraph supports
         | dynamic topologies too, ie. don't declare any hard edges, add a
         | conditional edge after every node
        
           | dbmikus wrote:
           | Good to know!
           | 
           | Is there a succinct explanation of the value that pregel
           | brings to LangGraph? Is it the 3 items I mentioned?
        
             | nfcampos wrote:
             | The value of using pregel is supporting cyclical graphs,
             | with concurrent tasks, but completely deterministic
             | behavior (eg. doesn't matter that task A this time happens
             | to finish before task B, its results will be applied in a
             | predetermined order, etc)
        
               | dbmikus wrote:
               | Making concurrent work deterministic and solving data
               | races makes sense.
               | 
               | Thanks for explaining! I didn't fully grok this from the
               | LangGraph docs
        
       | ausbah wrote:
       | it's amazing how the latest trend in software engineering feels
       | so unengineered. "if process doesn't work cross your fingers and
       | try again" feels like a religious sacrament
        
       ___________________________________________________________________
       (page generated 2024-08-09 23:01 UTC)