Launch HN: Danswer (YC W24) – निजी डेटा पर ओपन-सोर्स AI सर्च और चैट
Danswer नामक एक ओपन-सोर्स प्रोजेक्ट का उद्देश्य कंपनी के निजी ज्ञान पर AI-संचालित search और chat प्रदान करना है, जिसमें Slack, Google Drive, Confluence, GitHub और अन्य टूल्स से सामग्री को एकत्र किया जाता है। टिप्पणीकार यह जांचते हैं कि यह retrieval quality, access control, multilingual support, और scale पर incremental syncing को कैसे संभालता है, और इसकी तुलना in-house RAG prototypes तथा Microsoft Copilot या Glean जैसे commercial offerings से करते हैं। founders openness, self-hosting, extensible connectors, और retrieval quality पर फोकस को अपनी मुख्य बढ़त बताते हैं, जबकि paid cloud version और advanced enterprise features के माध्यम से monetization करते हैं.
उत्पाद का फोकस और भेदभाव
- इसे निजी कंपनी डेटा पर केंद्रित, टीम-उन्मुख “यूनिफाइड सर्च + AI चैट” के रूप में रखा गया है, न कि सिर्फ ChatGPT-जैसे UI के रूप में।
- RAG के retrieval हिस्से पर ज़ोर: Notion, Confluence, Jira, Slack, Google Drive, GitHub/GitLab आदि जैसे टूल्स के लिए connectors, incremental updates, metadata, और access control।
- विकल्पों (OpenWebUI, Glean, dust, Vectara, privateGPT, Copilot) की तुलना में Danswer open source, self-hosting, मजबूत retrieval, और multi-source aggregation पर ज़ोर देता है; दूसरों को अधिक proprietary, संकीर्ण, या “assistant/agent”-उन्मुख माना गया है।
ओपन सोर्स, बिज़नेस मॉडल, और moat
- कोर MIT-licensed है; paid cloud और कुछ advanced enterprise features (जैसे SAML/OIDC, expert-finding, advanced RBAC) proprietary हैं।
- रणनीति: छोटे और मध्यम आकार की teams को जीतना जो high-touch SaaS vendors की नज़र से छूट जाती हैं, और बड़े संगठनों को आकर्षित करना जो transparency, customization, और self-hosting चाहते हैं।
- FAANG/Copilot से प्रतिस्पर्धा को स्वीकार किया गया है, लेकिन founders का मानना है कि OSS + community + flexibility एक बचाव योग्य angle है।
आर्किटेक्चर, मॉडल, और retrieval गुणवत्ता
- Vespa को vector DB + search engine के रूप में इस्तेमाल किया गया है; hybrid search (keyword + embeddings), embeddings/rerankers के लिए CPU पर local ~100M-parameter models, default OpenAI LLM, लेकिन pluggable/open-weight models (Ollama के माध्यम से भी) उपलब्ध हैं।
- RAG pipeline में context-aware chunking (limited LlamaIndex उपयोग के माध्यम से), multi-granularity passes, feedback-based re-ranking, और time-based decay शामिल हैं।
- नया reranking approach: chunks “relevant” हैं या नहीं, सिर्फ़ यह नहीं, बल्कि “useful” हैं या नहीं—इसका निर्णय करने के लिए LLM का उपयोग; दावा है कि इससे standard cross-encoders से बेहतर परिणाम मिलते हैं।
सुरक्षा, privacy, और access control
- कई auth विकल्प (basic, Google OAuth; paid tier में OIDC/SAML)। domain-restricted signups समर्थित हैं।
- RBAC वर्तमान में connector-level पर है; sources (Google Drive, Confluence, Jira, Notion, Slack channel membership) से fine-grained permissions sync करने पर काम जारी है।
- SaaS के लिए, admins agreement के तहत डेटा तक पहुँच सकते हैं; self-hosted के लिए, infra admins के पास आमतौर पर source systems की पहले से पहुँच होती है। Air-gapped setups with local LLMs संभव हैं।
सीमाएँ, रोडमैप, और उपयोग के मामले
- वर्तमान gaps: अभी full code search नहीं है (सिर्फ PRs/issues), basic spreadsheet और PDF handling है, OCR या rich table/graph समझ नहीं है; ये roadmap पर हैं।
- Real-time/streaming ingestion आंशिक रूप से scaffolded है, लेकिन source API limits के कारण ज़्यादातर unused है।
- painful internal search वाली teams, खासकर consulting और enterprise/government, से strong interest और positive feedback मिला है; कुछ लोगों को LLM reasoning depth, private channels के लिए UX, और long-context knowledge exploration पर संदेह है.