This blog post demonstrates a Retrieval Augmented Generation (RAG) pipeline running entirely within a web browser. It uses Kuzu-WASM, a WebAssembly build of the Kuzu graph database, to store and query a knowledge graph, and WebLLM, a library for running large language models (LLMs) client-side. The demo allows users to query the graph using natural language, with Kuzu translating the query into its native query language and retrieving relevant information. This retrieved context is then fed to a local LLM (currently, a quantized version of Flan-T5), which generates a natural language response. This in-browser approach offers potential benefits in terms of privacy, reduced latency, and offline functionality, enabling new possibilities for interactive and personalized AI applications.
Theophile Cantelo has created Foudinge, a knowledge graph connecting restaurants and chefs. Leveraging Large Language Models (LLMs), Foudinge extracts information from various online sources like blogs, guides, and social media to establish relationships between culinary professionals and the establishments they've worked at or own. This allows for complex queries, such as finding all restaurants where a specific chef has worked, discovering connections between different chefs through shared work experiences, and exploring the culinary lineage within the restaurant industry. Currently focused on French gastronomy, the project aims to expand its scope geographically and improve data accuracy through community contributions and additional data sources.
Hacker News users generally expressed skepticism about the value proposition of the presented knowledge graph of restaurants and chefs. Several commenters questioned the accuracy and completeness of the data, especially given its reliance on LLMs. Some doubted the usefulness of connecting chefs to restaurants without further context, like the time period they worked there. Others pointed out the existing prevalence of this information on platforms like Wikipedia and guide sites, questioning the need for a new platform. The lack of a clear use case beyond basic information retrieval was a recurring theme, with some suggesting potential applications like tracking career progression or identifying emerging culinary trends, but ultimately finding the current implementation insufficient. A few commenters appreciated the technical effort, but overall the reception was lukewarm, focused on the need for demonstrable practical application and improved data quality.
This blog post explores different ways to represent graph data within PostgreSQL. It primarily focuses on the adjacency list model, using a simple table with "source" and "target" columns to define relationships between nodes. The author demonstrates how to perform common graph operations like finding neighbors and traversing paths using recursive CTEs (Common Table Expressions). While acknowledging other models like adjacency matrix and nested sets, the post emphasizes the adjacency list's simplicity and efficiency for many graph use cases within a relational database context. It also briefly touches on performance considerations and the potential for using materialized views for complex or frequently executed queries.
Hacker News users discussed the practicality and performance implications of representing graphs in PostgreSQL. Several commenters highlighted the existence of specialized graph databases like Neo4j and questioned the suitability of PostgreSQL for complex graph operations, especially at scale. Concerns were raised about the performance of recursive queries and the difficulty of managing deeply nested relationships. Some suggested that while PostgreSQL can handle simpler graph scenarios, dedicated graph databases offer better performance and features for more complex graph use cases. A few commenters mentioned alternative approaches within PostgreSQL, such as using JSON fields or the extension pg_graphql. Others pointed out the benefits of using PostgreSQL for graphs when the graph aspect is secondary to other relational data needs already served by the database.
Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43321523
HN commenters generally expressed excitement about the potential of in-browser graph RAG, praising the demo's responsiveness and the possibilities it opens up for privacy-preserving, local AI applications. Several users questioned the performance and scalability with larger datasets, highlighting the current limitations of WASM and browser storage. Some suggested potential applications, like analyzing personal knowledge graphs or interacting with codebases. Concerns were raised about the security implications of running LLMs client-side, and the challenge of keeping WASM binaries up-to-date. The closed-source nature of KuzuDB also prompted discussion, with some advocating for open-source alternatives. Several commenters expressed interest in trying the demo and exploring its capabilities further.
The Hacker News post discussing in-browser graph RAG with Kuzu-WASM and WebLLM has generated several comments, offering a range of perspectives on the project.
One commenter expresses excitement about the potential of WebAssembly for database applications, specifically highlighting the possibility of running complex queries client-side without server dependencies. They see this as a significant step toward enabling powerful and responsive web applications. They also inquire about the feasibility of using this technology with larger datasets, acknowledging the current limitations of browser storage.
Another commenter raises a practical concern about the performance implications of handling large graph datasets within the browser. They question whether the current implementation can efficiently manage substantial graphs and suggest that server-side processing might be more suitable for complex graph operations on large datasets. This comment highlights a common trade-off between client-side convenience and server-side performance when dealing with data-intensive applications.
A further comment delves into the specifics of the technology, mentioning the use of Apache Arrow for data serialization. They posit that this choice could be contributing to performance bottlenecks, particularly when transferring data between JavaScript and WebAssembly. They suggest exploring alternative serialization methods or optimizing the data transfer process to improve overall efficiency.
Another individual inquires about the licensing of the project, expressing interest in its potential applications. This highlights the importance of clear licensing information for open-source projects to encourage adoption and collaboration.
The discussion also touches upon the security implications of running database queries within the browser environment. One comment raises the concern of potential vulnerabilities arising from client-side execution and suggests that careful consideration should be given to security best practices.
Finally, a commenter expresses enthusiasm for the project's potential to democratize access to graph databases, making them more accessible to developers and users without requiring specialized server infrastructure. They see this as a positive step towards empowering individuals and smaller organizations to leverage the power of graph technology.
In summary, the comments on the Hacker News post reflect a general interest in the project while also raising important questions and concerns regarding performance, scalability, security, and licensing. The discussion highlights the potential benefits and challenges of bringing graph database technology to the browser environment.