I should, perhaps, add an FAQ section addressing the hows and whys of Griptape :)
In short, Griptape is different from LangChain in the following ways:
- Instead of chained agents, it uses more general-purpose DAGs and pipelines. Think of it as Airflow for LLMs. It still implements chain of thought logic for prompt workflow steps that use tools but it also supports any kind of input and output (think images, audio, etc.).
- Griptape tools are designed to be decoupled from the caller logic and execution environments. For example, tools can be easily run in a Docker container or a Lambda function (as opposed to just YOLOing LLM-generated Python code on the local box).
- Tools can be plugged into other LLM frameworks through adapters. For example, you can convert any Griptape tool into a LangChain tool or generate a ChatGPT Plugin API with a single line of code. This is the only place Griptape actually references LangChain in code, afaik :)
Issues do need to be moved from a private Trello into GitHub (still early days...)—I can ping when that's done—are you on Griptape Discord?
The WebScraper tool uses Trafilatura [1] to scrape and parse HTML—nothing too fancy. "Scraping" a React site would require a totally different approach, probably something more akin to Adept's ACT-1 [2].
I run a local chat app built with Griptape and I use it to give me summaries of web pages or answer specific questions all the time :)
I think BeautifulSoup is great but it's more of a set of building blocks that requires developers to implement their custom scraping logic. Trafilatura is awesome because it just works out of the box for most common tasks related to web scraping.
Current version of MerLoc is similar to SST except some minor details.
The biggest difference so far is that you can use MerLoc with any deployment tool like AWS CDK, AWS CloudFormation, AWS SAM, Serverless Framework, SST, Terraform, etc ...
And we are also working on an improvement which will let you use the same network with the remote function on your local.
1. Currently, if I install something in the notebook, does it get re-installed every time the pipeline is run? Is there any way to "snapshot" the state of the container?
2. Where is the data stored between the steps?
3. How well-integrated is it with AWS cloud primitives such as EC2 instances, EFS, and S3?
1. Right now additional dependencies for the container need to be re-installed whenever you run the pipeline. During the entire Jupyter kernel session though, the container state and thus any installed dependencies remain available. We're working on either supporting container snapshots or custom container images (with desired dependencies pre-installed). We'll likely go with snaphots as they'll be easier from an end-user perspective.
2. During step execution data is stored inside of either the pipeline directory (which contains for example the .ipynb/.py/.R/.sh files) or in any of the mounted directories (through data sources).
When you run the pipeline as part of an experiment a copy is created so that any state generated by any of the steps inside of the pipeline directory is isolated from the 'working copy' of the pipeline.
Edit: forgot to mention that we support memory-based data transfer between steps which is faster and doesn't "pollute" your pipeline directory. It does require your data to fit in memory though. We use Apache Arrow's Plasma for this.
It seems like it uses Docker instead of custom cluster-building logic. I'm not sure if there are differences between how it slows down the network and creates partitions.
Hi! I launched OpsLog a few weeks ago. Its purpose is to analyze team's on-call and pull request data to quantify operations impact and software engineering progress.
I'd love to get some feedback on the product and the problem that I'm trying to solve. I'm also wondering what HN folks generally struggle with when it comes to analyzing and improving on-call at the team and org levels.
I'm not sure I agree with the listed reasons. From what I understood, the author tries to prove that "SaaS is eating SaaS" and SaaS abundance/switching costs are prohibitive to new SaaS ventures. This doesn't seem like a very good argument for "SaaS is dying." May be, it's better suited for "it's becoming more difficult to enter the SaaS game."
Sounds like SaaS is falling under standard business rules. You have a core product and you have differentiators. A single, great core product was fine for a long time. As more players enter the market, the differentiators matter more.
In short, Griptape is different from LangChain in the following ways:
- Instead of chained agents, it uses more general-purpose DAGs and pipelines. Think of it as Airflow for LLMs. It still implements chain of thought logic for prompt workflow steps that use tools but it also supports any kind of input and output (think images, audio, etc.). - Griptape tools are designed to be decoupled from the caller logic and execution environments. For example, tools can be easily run in a Docker container or a Lambda function (as opposed to just YOLOing LLM-generated Python code on the local box). - Tools can be plugged into other LLM frameworks through adapters. For example, you can convert any Griptape tool into a LangChain tool or generate a ChatGPT Plugin API with a single line of code. This is the only place Griptape actually references LangChain in code, afaik :)
Issues do need to be moved from a private Trello into GitHub (still early days...)—I can ping when that's done—are you on Griptape Discord?