3 ms·

Show HN: AI Chat for Research with References (>10-20 PDFs, No Hallucinations)

2 points by AS_YC 2y ago

Hey HN, We’ve built Wallstr.chat, an AI-powered research tool that helps anyone working with long PDFs extract key insights instantly - with source references for every data point. It can handle 10-20+ PDFs in parallel, making it ideal for finance, research, and deep document analysis. Why it’s different: - No hallucinations (every insight is backed by a direct source reference from your PDFs) - Handles 10-20+ PDFs at once (analyze multiple reports in a single chat) - Fast & structured insights (extract key figures, tables, and references effortlessly) - Investment-grade accuracy (built for 10-Ks, earnings reports, investor decks, and research papers) Features: - Reference exact data points (every number/thesis is sourced, with the source paragraph highlighted) - Generate investment memos in under 60 seconds (custom templates coming soon) It’s open-source, so you can run it locally. GitHub: https://github.com/limanAI/wallstr https://github.com/limanAI/wallstr If you find this useful, please star the repo!

mdp2021 2y ago
Could you provide a bit of technical information? The part about the abatement of hallucination would be especially of interest. So have you assessed that llama3.2 (3B, I imagine - also 1B exists) is enough to answer properly to the sought level of accuracy? Did you use nomic to create embeddings of the local body of knowledge?
- AS_YC 2y ago
  We minimized hallucinations mainly by tuning the chunk size, document partitioning, and embedding distance thresholds. In our experience, when you provide high-quality and accurate context, hallucinations become quite rare. That said, it heavily depends on the LLM you’re using — hallucinations are more common with models like Gemini or local LLaMA variants. We’re currently working on extracting pre-structured data (like income statements and cash flows) during PDF processing. We aim to populate these structures upfront and then use tools or special functions to query them. That helps us reduce LLM overhead and improve reliability. The current setup is already working quite well. "So have you assessed that llama3.2 (3B, I imagine — also 1B exists) is enough to answer properly to the sought level of accuracy?" It depends on the use case. Our service is designed to support multiple LLMs, but the best results come from models like GPT-4o or DeepSeek-r1. Initially, we focused on local models and used LLaMA 3.2–3B along with Nomic embeddings, but we eventually moved to more powerful cloud-based models. The main driver was the need to extract structured information (like tables/images) from PDFs. We crop those elements and pass them to vision-capable LLMs to retrieve structured JSON. Running models like LLaVA locally on a Mac was too slow for this use case, and traditional OCR didn’t give the accuracy we needed. So while our stack can still run locally (with somewhat lower quality), we now default to general-purpose cloud LLMs for better performance and accuracy

2 points by AS_YC 2y ago

mdp2021 2y ago

Could you provide a bit of technical information? The part about the abatement of hallucination would be especially of interest. So have you assessed that llama3.2 (3B, I imagine - also 1B exists) is enough to answer properly to the sought level of accuracy? Did you use nomic to create embeddings of the local body of knowledge?

AS_YC 2y ago
We minimized hallucinations mainly by tuning the chunk size, document partitioning, and embedding distance thresholds. In our experience, when you provide high-quality and accurate context, hallucinations become quite rare. That said, it heavily depends on the LLM you’re using — hallucinations are more common with models like Gemini or local LLaMA variants. We’re currently working on extracting pre-structured data (like income statements and cash flows) during PDF processing. We aim to populate these structures upfront and then use tools or special functions to query them. That helps us reduce LLM overhead and improve reliability. The current setup is already working quite well. "So have you assessed that llama3.2 (3B, I imagine — also 1B exists) is enough to answer properly to the sought level of accuracy?" It depends on the use case. Our service is designed to support multiple LLMs, but the best results come from models like GPT-4o or DeepSeek-r1. Initially, we focused on local models and used LLaMA 3.2–3B along with Nomic embeddings, but we eventually moved to more powerful cloud-based models. The main driver was the need to extract structured information (like tables/images) from PDFs. We crop those elements and pass them to vision-capable LLMs to retrieve structured JSON. Running models like LLaVA locally on a Mac was too slow for this use case, and traditional OCR didn’t give the accuracy we needed. So while our stack can still run locally (with somewhat lower quality), we now default to general-purpose cloud LLMs for better performance and accuracy