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.
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 ( 16 )
https://news.ycombinator.com/item?id=43242818
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.
The Hacker News post titled "Show HN: Knowledge graph of restaurants and chefs, built using LLMs" generated a moderate amount of discussion, with a focus on the practical application and potential limitations of the project.
Several commenters expressed interest in the project's potential, particularly regarding its use for restaurant recommendations. One commenter highlighted the difficulty of finding good restaurants in unfamiliar cities and suggested the knowledge graph could be helpful in this scenario, particularly if it allowed users to filter by cuisine type and other specific criteria. They also inquired about the possibility of incorporating user reviews or ratings into the system.
Another user echoed this sentiment, pointing out that existing restaurant recommendation platforms often rely on outdated or inaccurate information. They envisioned the project as a valuable tool for both diners and restaurant owners, providing a centralized and up-to-date resource for restaurant information.
However, some commenters expressed concerns about the project's reliance on LLMs. One commenter pointed out the potential for hallucinations and inaccuracies in LLM-generated data, emphasizing the importance of thorough verification and fact-checking. They also questioned the long-term viability of relying solely on LLMs for data collection and maintenance, suggesting that a more robust approach might involve incorporating human input and curation.
The creator of the project engaged with the commenters, acknowledging the challenges of LLM-based data generation and outlining plans to address these concerns. They mentioned plans to implement a feedback mechanism to flag inaccurate information and explore methods for verifying the accuracy of LLM-generated data. They also discussed potential future features, such as incorporating user reviews, dietary information, and real-time menu updates.
A recurring theme in the comments was the need for a practical application or interface for the knowledge graph. Commenters suggested various use cases, including a dedicated search engine for restaurants, a mobile app for on-the-go recommendations, and integration with existing restaurant platforms.
Finally, one commenter raised a broader point about the ethical implications of using LLMs to scrape data from the web, questioning the potential impact on website owners and the overall ecosystem of online information. This sparked a brief discussion about the responsible use of LLMs and the importance of respecting website terms of service. While not directly related to the project itself, this comment highlighted the broader ethical considerations surrounding LLM-driven data collection.