文章介绍了如何构建本地RAG(检索增强生成)系统,强调隐私保护的重要性,无需依赖第三方服务。核心包括向量数据库、嵌入模型和LLM等组件,并对比了使用专有API与自托管开源技术的性能差异,为隐私敏感组织提供了解决方案。

标题：如何构建本地化RAG系统？——开源替代方案与性能实测

核心内容：

1. 背景与目标

• Skald项目旨在提供可自托管且不依赖第三方数据的解决方案
• 在LLM快速发展的背景下，为注重隐私的组织提供不妥协数据安全的AI方案

2. RAG核心组件与开源替代方案 基础组件：

• 向量数据库（Qdrant/Weaviate/pgvector替代Pinecone等商业方案）
• 向量嵌入模型（Sentence Transformers/BGE替代OpenAI/Cohere）
• LLM（Llama/Mistral替代GPT/Claude）

增强组件： - 重排序器（BGE Reranker替代Cohere） - 文档解析（Docling替代Reducto）

3. Skald技术栈实践 当前配置：

• 向量数据库：Postgres+pgvector（支持数十万文档）
• 默认嵌入模型：all-MiniLM-L6-v2（英语专用）
• LLM：用户自选（测试使用GPT-OSS 20B）
• 重排序器：Sentence Transformers跨编码器
• 文档解析：Docling

4. 性能测试结果 对比三种配置：

• 云端方案（Voyage+Claude）：平均分9.45
• 混合方案（Voyage+GPT-OSS 20B）：平均分9.18
• 全本地方案：
  • 默认英语模型：平均分7.10（多文档聚合表现欠佳）
  • 多语言模型（bge-m3）：平均分8.63（支持葡萄牙语查询）

5. 关键发现

• 本地方案已能满足基础需求
• 多文档信息聚合仍是挑战
• 模型选择需权衡性能与语言支持

6. 未来计划

• 优化多文档聚合能力
• 开展更系统的开源模型基准测试
• 服务更多隔离网络环境需求

（注：原文中的具体测试参数、部分技术细节及推广内容已适当精简，保留核心技术方案和关键测试结果）

以下是评论内容的总结：

1. 语义分块的重要性

   • 建议使用语义分块（如spacy）提升RAG系统性能，并引用Anthropic的上下文检索方法
   • 关键引用："embedding entire docs breaks down if docs contain multiple concepts" / "append context to how this chunk relates to the rest of your doc"

2. 全文搜索的实用性

   • 认为全文搜索（如grep）比向量数据库更经济高效，LLM可自主优化搜索词
   • 关键引用："Full text search or even grep are faster and cheaper" / "LLM can come up with searches like 'dog OR canine'"

3. 语义搜索的质疑

   • 质疑语义搜索是否显著优于传统词法搜索（如BM25），认为工程成本可能过高
   • 关键引用："semantic search results marginally different from lexical" / "does the problem warrant this multi-component approach"

4. 本地化实施的建议

   • 推荐分阶段实施本地RAG，优先处理文档和向量数据库而非LLM
   • 关键引用："having documents and vector db locally is a huge first step"
   • 另有用户推荐现成工具如AnythingLLM和byte-vision（支持Llama.cpp）

5. 技术选型的经验分享

   • 推荐Nomic和Qwen3嵌入模型，但后者延迟较高；SQLite-vec在CLI工具中表现良好
   • 关键引用："good results with nomic" / "sqlite-vec worked well for cli tool"

6. 其他补充建议

   • 呼吁建立标准测试数据集评估RAG效果
   • 提醒注意使用前沿模型时的隐私保护（推荐Zink工具）

（注：所有评论均无评分数据，故未标注认可度）