Thanks for the feedback-- I can say emphatically, that's not our intention in the least. We chose a lightning bolt to evoke speed, i.e., the "hyper" in Hypermode. I've asked design to take another look at the "H" logo.
48 karma · joined February 25, 2015
I think there's a big advantage to be had for folks brining "old school" ML approaches to LLMs. We've been spending a lot of time looking at the expert systems from the 90s.
Another one we've been looking at is applying some query planning approaches to these systems to see if we can pull responses from cache instead of invoking the model again.
Obviously there's a lot of complexity to identifying where we could apply some smaller ML models or cache-- but it's been a really fun exploration.
What we've seen most successful is making recommendations in the agent creation process for a given tool/workload and then leaving them somewhat static after creation.
There's a waitlist for our prompt to agent product in the banner. That's a good call to update it to be more clear.
Agreed on swapping models for code-gen doesn't make sense. We're mostly indexed on GPT-4.1 for our AgentBuilder product. I haven't found it easy to move between models for code super effective.
The most popular use case we've seen from folks is on the iteration/experimentation phase of building an agent/tool. We made ModelRouter originally as an internal service for our "prompt to agent" product, where folks are trying a few dozen models/MCPs/tools/data/etc really quickly as they try to find a local maximum for some automation or job.
If deploying a Next.js site, it makes sense to deploy on top of the platform made for it (ZEIT/Vercel)
Tray does a really good job as a general purpose automation platform. It’s really extensible and allows technical users to pull the covers off and do a lot more and semi-technical business users to get by without code.
At a high level: I’d go with workato if I had an acute problem that I needed fixed quickly. I’d go with tray if I saw automation being a long term strategy at my company where I know I’m going to need lots of flexibility integrating legacy applications with SaaS, etc.
neo4j.com
devrel at neo4j dot com
0.13*31BN = ~$4BN, still a 10X return if they've invested $400M.
eBay (ShopBot) is a Neo4j powered ML chatbot. AirBnb also builds knowledge graphs with Neo4j.
Video from GraphConnect today talking about knowledge graphs: https://youtu.be/dqrlotzdUlo?t=3175
Transparency: I'm an employee at Neo4j.
e.g.,
//grabs literally EVERY node in your database
MATCH (Person)-[KNOWS]-(Friend)
//only the people who have a KNOWS relationship between them
MATCH (person:Person)-[:KNOWS]-(Friend:Person)
It's a single image database (no partitioning except in memory), so all nodes in the cluster will have the complete dataset (thus each node must be large enough to store it). However, because Neo4j doesn't rely on joins / table scans to operate-- traversals are O(1) not O(n). So there's an advantage to doing OLTP work on really really large datasets that have a specific starting point. Neo4j will do pointer arithmetic instead of scans / joins, such that regardless of dataset size a query will only access the fixed amount of data. The reason for this strategy has been that scale up hardware pricing has come down incredibly quickly in the last decade and having a trio of 64+++ GB memory boxes isn't out of the question for most mid-size and enterprise companies. Secondly, distributed systems are non-trival problems to manage both from a development but a devops perspective as well.
The philosophy of the Neo4j team is to conquer the world slowly. In order of priority Neo4j is designed around:
1.) data integrity and availability (ACID transactions, master-slave replication)
2.) rapid reads for graph traversals
3.) ability to store web-scale datasets (trillions++ of nodes)
4.) parallel operations (multi-master, map-reduce, global analytics, etc.)
The product has firmly completely 1 and 2, and is starting to work on 3 and 4 (4 mostly with a databricks / spark partnership).
It fights the same CAP problem that all databases do. We've chosen Consistency and Availability. Partition tolerance just isn't something inherent to graph databases. We can do some really smart math and duplicate nodes with high betweenness centrality (data nodes, not servers) or shuffle data based on access patterns to prevent introducing network latency into query plans that access nodes on multiple partitions. But doing that while maintaining 1 and 2 of the above is very not easy.
Disclaimer:
MATCH (rhino)-[:WORKS_AT]->(neo4j)
WHERE NOT rhino.opinions = neo4j.opinions
Understanding {buzzword pop culture / news topic} using {conference language} + {pick 3+ of [real-time, cloud, at scale, data science, docker, sentiment analysis, polyglot persistence]}
It works shamefully well.
Gremlin was originally developed by Neo4j co-founder Peter Neubaurer and Marko Rodriguez (Titan founder) while they were both working at Neo4j.
It's been in mission critical prod. environments now for nearly a decade. I'm certain that in the future DSE, Orient, Arango, or someone like them will be big contenders in the space. However, for the time being, I wouldn't trust anything critical to them.