# Omni：用 Postgres pgvector 构建职场 RAG 搜索与聊天，无需向量数据库 > 开源 Omni 项目基于 Postgres ParadeDB + pgvector，实现混合搜索、RAG 聊天和对话历史存储，支持职场工具连接，自托管部署参数与优化要点。 ## 元数据 - 路径: /posts/2026/03/02/omni-postgres-pgvector-workplace-rag-search-chat/ - 发布时间: 2026-03-02T20:01:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在现代职场，员工每天需要在 Google Drive、Slack、Confluence、Jira 等多个分散工具中搜索信息、文档和对话记录。这种碎片化导致效率低下。传统 RAG（Retrieval-Augmented Generation）解决方案往往依赖 Elasticsearch 处理全文搜索、专用向量数据库如 Pinecone 或 Weaviate 存储嵌入向量，再叠加 LLM 服务。这种架构虽强大，但带来高运维成本、多组件协调复杂、数据隐私隐患等问题。 开源项目 Omni 提供了一个极简、高效的替代方案：**一切数据与搜索逻辑全托管在 Postgres 中，利用 pgvector 扩展实现嵌入存储与检索，ParadeDB 处理 BM25 全文搜索，无需任何外部向量数据库或搜索引擎**。这不仅简化了部署，还确保数据主权完全自控。Omni 支持统一搜索、多模态 RAG 聊天、权限继承，适用于中小团队自托管。 ## 核心架构：Postgres 为王 Omni 的设计哲学是“一个数据库搞定一切”。Postgres 作为核心存储： - **全文搜索**：ParadeDB（Postgres + Tantivy 引擎）构建 BM25 索引，支持高效关键词匹配。 - **语义搜索**：pgvector 存储文档 chunk 的嵌入向量，使用 HNSW（Hierarchical Navigable Small World）算法进行 ANN（Approximate Nearest Neighbors）检索。 - **混合搜索（Hybrid Search）**：融合 BM25 分数与余弦相似度，公式大致为 `score = α * norm_bm25 + (1 - α) * cosine_sim`，其中 α 通常设为 0.3~0.7，根据领域调优。 - **应用数据**：用户、连接器配置、对话历史、权限元数据全存 Postgres，避免多库同步。 如官方文档所述，AI Agent 通过工具调用（如 `search(query)`、`retrieve_doc(id)`）查询索引，实现高级 RAG：不止 top-k 检索，还支持过滤、排序和多轮对话上下文注入。对话历史持久化在 `conversations` 表中，支持无限长上下文管理。 在 HN 讨论中，作者提到：“I've done small scale experiments with up to 100-500k rows, and did not notice any significant degradation in search query latency - p95 still well under 1s。” 这种 Postgres-only 方案的落地参数： - **嵌入模型**：推荐 OpenAI `text-embedding-3-small`（维度 1536，低成本，高性能）或自托管 `BAAI/bge-large-en-v1.5`。 - **Chunking**：文档切块大小 512 tokens，重叠 20%，确保检索粒度合适。 - **pgvector HNSW 参数**： | 参数 | 推荐值 | 说明 | |------|--------|------| | m | 16~32 | 每个节点的 max 连接数，越大 recall 越高但内存/构建慢 | | ef_construction | 128~256 | 索引构建时搜索范围，影响构建时间与质量 | | ef_search | 40~100 | 查询时搜索范围，平衡速度与召回 | 创建索引 SQL 示例： ```sql CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 128); ``` ## 快速部署与配置清单 Omni 部署门槛极低，单机 Docker Compose 即可运行生产级服务。 1. **环境准备**： - Docker 24+，Postgres 16+（启用 pgvector 和 ParadeDB 扩展）。 - 硬件：8GB RAM，SSD 存储（索引规模 1M docs 需 ~50GB）。 2. **克隆与配置**： ``` git clone https://github.com/getomnico/omni.git cd omni cp .env.example .env ``` 编辑 `.env`： ``` POSTGRES_URL=postgresql://omni:omni@localhost:5432/omni EMBEDDING_PROVIDER=openai OPENAI_API_KEY=sk-... LLM_PROVIDER=anthropic # 或 openai/gemini/vllm ANTHROPIC_API_KEY=... ``` 3. **启动**： ``` docker compose up -d ``` 访问 http://localhost:3000，创建 admin 用户。 4. **添加连接器**： - **Google Workspace**：上传 Service Account JSON，授权 Drive/Gmail scopes。 - **Slack**：Bot Token + App ID，索引 public channels（private 需额外权限映射）。 - **Confluence/Jira**：API Token + Base URL。 每个连接器独立容器运行，支持自定义 SDK（Python/TS）。 5. **初始索引**：UI 中触发全量同步，监控 `connector_runs` 表进度。 生产部署用 Terraform（AWS/GCP），自动 provision RDS + EKS。 ## RAG 聊天与高级功能 - **搜索 UI**：输入 query，返回 hybrid top-10 结果 + 高亮片段。 - **聊天 UI**：LLM 自动调用工具检索，生成带 citation 的回答。支持 Python/Bash sandbox 执行（隔离 Docker 网络，无网访问）。 - **权限控制**：应用层 WHERE 子句过滤（如 `user_id IN (source_perms)`），未来升级 Postgres RLS。Slack private channels 通过成员列表动态更新权限。 可落地提示模板： ``` Context: {retrieved_docs} User: {query} Assistant: Answer based on context, cite sources. ``` ## 优化、监控与风险缓解 **性能调优**： - Hybrid α：关键词重域设 0.7，语义重设 0.3。用 A/B 测试评估 NDCG@10。 - 索引维护：每周增量 upsert，避免全 rebuild。使用 `pg_repack` 重组大表。 - Scale：500k docs 单实例足用；超 10M 分库（Citus）或读副本。 **监控清单**： - Prometheus 指标：`search_query_latency_p95 < 500ms`，`index_build_duration`。 - Alert：embedding queue >1000，permission_drift。 - Logs：Rust searcher 日志追踪 HNSW recall。 **潜在风险**： 1. **权限同步延迟**：Slack members 变更需实时 webhook，fallback 用 cron 每小时 sync。 2. **LLM 幻觉**：强制 tool use + citation，必选 verified sources。 3. **成本**：BYO LLM，监控 token 用量；vLLM 自托管开源模型降本 90%。 回滚策略：索引快照（pg_dump），Docker rollback。 Omni 证明了 Postgres pgvector 已成熟到取代专用 vector DB，用于生产 RAG workplace search。相比 SaaS 如 Glean，节省 80% 成本，自控数据。 **资料来源**： - [GitHub Repo](https://github.com/getomnico/omni) - [HN Discussion](https://news.ycombinator.com/item?id=47215427) - [Official Docs](https://docs.getomni.co/) ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。