# GEO平台知识库系统 - 开源框架与技术方案综合调研报告

**调研时间**: 2026年5月23日 | **项目**: GEO平台知识库系统

## 执行摘要

### 推荐方案（分层递进）
- **核心RAG引擎**: LangChain + LlamaIndex（互补优势）
- **向量数据库**: pgvector（生产）+ Chroma（开发）
- **文档处理**: Unstructured + LangChain Document Loaders
- **Embedding**: BAAI/bge-m3（中英文混合）
- **RAG调优**: Hybrid Search + 递归语义分块 + 重排
- **架构理念**: Harness Pipeline-as-Code + Context Engineering

---

## 第一部分：RAG框架对标分析

### 主流框架概览

| 框架 | GitHub Stars | 核心定位 | 推荐度 |
|-----|------------|--------|--------|
| **LangChain** | ~200k | 通用LLM应用框架，Agent编排 | ⭐⭐⭐⭐⭐ |
| **LlamaIndex** | ~60k | 文档RAG专家，数据连接 | ⭐⭐⭐⭐⭐ |
| **Dify** | ~121k | 企业级完整平台 | ⭐⭐⭐ (参考用) |
| **RAGFlow** | ~70k | 复杂文档处理 | ⭐⭐⭐ |
| **FastGPT** | ~40k | 轻量知识库 | ⭐⭐⭐ (参考用) |
| **MaxKB** | ~15k | 企业内部知识库 | ⭐⭐ |

### 为什么不选全栈平台？

❌ **Dify/FastGPT的问题**：
- 学习曲线陡（新的工作流DSL）
- 定制成本高（改一个逻辑要修改整个平台）
- 与FastAPI不兼容，技术债
- 长期维护困难

✅ **LangChain + LlamaIndex方案**：
- 两者互补：LangChain用于Agent编排，LlamaIndex用于文档处理
- 与FastAPI无缝集成
- 社区资源最丰富
- 定制成本低，长期收益大

---

## 第二部分：向量数据库方案

### 对比分析

| 数据库 | 部署 | 优势 | 劣势 | GEO适配度 |
|-------|------|------|------|---------|
| **pgvector** | PG扩展 | 无缝集成、ACID、成本低 | 性能有上限 | ⭐⭐⭐⭐⭐ |
| **Chroma** | 本地/容器 | 轻量、零配置、开发友好 | 功能简单 | ⭐⭐⭐⭐ |
| **Qdrant** | 自托管 | 生产级、性能强 | 额外部署 | ⭐⭐⭐ |
| **Milvus** | 自托管 | 高性能、大规模 | 运维复杂 | ⭐⭐ |

### 推荐方案：pgvector + Chroma双层

```
生产环境：pgvector（PostgreSQL扩展）
  ✓ 向量与元数据同库存储
  ✓ 支持ACID事务、完整备份
  ✓ 成本最低，无额外部署
  ✓ 支持1M-10M向量级别

开发环境：Chroma
  ✓ 本地内存/SQLite存储
  ✓ 启动快，无需PG
  ✓ 快速原型验证
```

---

## 第三部分：文档处理和Embedding方案

### 三层处理管道

```
原始文档(PDF/Word/网页)
    ↓
Unstructured IO (文档解析)
    ↓
LangChain DocumentLoader (多源连接)
    ↓
分块策略选择
    ↓
BAAI/bge-m3 Embedding转向量
    ↓
pgvector存储
```

### 分块策略对比

| 方法 | 优势 | 劣势 | GEO推荐 |
|-----|------|------|--------|
| 固定大小512 token | 快速、简单 | 语义边界被切割 | ⭐ |
| 递归语义分块 | 保留逻辑结构、效果最优 | 实现复杂 | ⭐⭐⭐⭐⭐ |
| LLM驱动分块 | 最准确 | 成本高、延迟大 | ⭐⭐ |

**推荐：递归语义分块**
```python
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n\n", "\n\n", "\n", " ", ""]
)
```

### Embedding模型选型

**推荐：BAAI/bge-m3**
- 中英文混合优化
- 同时支持密集+稀疏检索
- 可直接微调
- 开源免费

```python
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("BAAI/bge-m3")
embeddings = model.encode(documents)
```

---

## 第四部分：RAG核心调优策略

### 4.1 Hybrid Search（混合检索）

**问题**：纯向量搜索弱于"精确术语查找"

**解决方案**：BM25（关键词）+ 向量（语义）+ 重排

```
查询 → BM25检索 → 关键词Top-K
     → 向量检索 → 语义Top-K
     → 分数融合（alpha融合）
     → Cross-Encoder重排
     → 最终排序
```

**参数建议**：
- 行业知识库（规则文档）：alpha = 0.3-0.4
- 企业知识库（描述性）：alpha = 0.5-0.6
- 内容生成辅助：alpha = 0.6-0.7

### 4.2 Query Expansion（查询扩展）

用LLM生成查询变体，提高召回率：

```python
class QueryExpander:
    async def expand_query(self, query: str, llm) -> List[str]:
        """生成3-5个查询变体"""
        prompt = f"""生成'{query}'的5个等价查询"""
        variants = await llm.agenerate(prompt)
        return [query] + variants
```

### 4.3 Context Window管理

避免"Lost in the Middle"问题：

```
【系统提示词】(必须)
【工具定义】(必须)
【关键指令】(高优先级)
【检索文档】(按token预算分配)
【用户查询】(放在最后 - 注意力最高)
```

---

## 第五部分：System Prompt设计 - Context Engineering

### 从Prompt到Context Engineering的演进

| 维度 | Prompt Engineering | Context Engineering |
|-----|------------------|-------------------|
| 范围 | 单次离散任务 | 持续Agent循环 |
| 重点 | 怎么问 | 整体信息状态 |
| 维护 | 写一次 | 动态策划 |

### 模块化Prompt结构

```xml
<system_prompt>
  <role>内容生成助手</role>
  <constraints>禁止编造数据、使用引用...</constraints>
  <knowledge_base_guide>
    - industry_knowledge：行业规则
    - company_knowledge：企业特定信息
  </knowledge_base_guide>
  <available_tools>
    - search_knowledge_base()
    - get_platform_rules()
    - check_brand_alignment()
  </available_tools>
  <output_format>
    {
      "content": "...",
      "sources": [...],
      "confidence": 0.95
    }
  </output_format>
</system_prompt>
```

### 多Agent Prompt模板

```python
# ContentGenerator Agent
"根据选题和知识库生成优质内容..."

# DeAI Agent
"消除AI生成痕迹，增加具体例子..."

# GEOOptimizer Agent
"优化关键词密度、H1/H2结构..."

# RuleChecker Agent
"检查是否符合平台规则..."
```

---

## 第六部分：Harness Engineering架构理念

### Pipeline-as-Code概念应用

采用Harness风格的YAML定义Pipeline：

```yaml
pipeline:
  stages:
    - stage_id: "topic_selection"
      agent: "TopicSelectorAgent"
      inputs: { strategy: "${TOPIC_STRATEGY}" }
      
    - stage_id: "knowledge_retrieval"
      agent: "KnowledgeRetrieverAgent"
      depends_on: ["topic_selection"]
      inputs:
        hybrid_search: { alpha: 0.5, top_k: 10 }
        
    - stage_id: "content_generation"
      depends_on: ["knowledge_retrieval"]
      
    # ...更多Stages
```

### 模块化和插件化架构

所有Stage都继承StagePlugin基类：

```python
class StagePlugin(ABC):
    @abstractmethod
    async def execute(self, context: dict) -> dict:
        pass
    
    def validate_inputs(self, inputs: dict) -> bool:
        pass

class PipelineEngine:
    def register_stage(self, stage_type: str, plugin: StagePlugin):
        """注册新Stage，实现插件化"""
        self.stage_registry[stage_type] = plugin
    
    def add_policy(self, policy_func):
        """Policy as Code - 治理规则"""
        self.policies.append(policy_func)
```

### 可观测性（OpenTelemetry模式）

```python
with self.tracer.start_as_current_span("pipeline_execution") as span:
    span.set_attribute("pipeline.name", "content_generation")
    
    for stage in stages:
        with self.tracer.start_as_current_span(f"stage_{stage}") as s:
            s.set_attribute("agent.tokens.input", 1024)
            s.set_attribute("agent.tokens.output", 512)
```

---

## 第七部分：完整的技术栈

```
┌─────────────────────────────────────────────┐
│ 前端(Next.js 14)                           │
│ - 知识库管理UI(参考Dify设计)               │
│ - 文档上传/预览/分块测试                    │
└────────────────┬────────────────────────────┘
                 │ REST API
┌────────────────▼────────────────────────────┐
│ FastAPI后端                                 │
│ - Knowledge Base APIs (新增)               │
│ - Retrieval APIs (新增)                    │
│ - Agent Pipeline APIs (新增)               │
└────────────────┬────────────────────────────┘
                 │
    ┌────────────┴────────────┐
    │                         │
┌───▼──────┐         ┌───────▼────┐
│业务逻辑层  │         │Agent框架层  │
│LangChain │         │LangGraph   │
│LlamaIndex │         │自定义Agent │
└───┬──────┘         └───┬────────┘
    │                    │
    └────────┬───────────┘
             │
┌────────────▼─────────────────────┐
│ 数据处理层                        │
│ - Unstructured IO                │
│ - Document Loaders               │
│ - 递归语义分块                    │
│ - Embedding (BAAI/bge-m3)        │
└────────────┬─────────────────────┘
             │
┌────────────▼──────────────────┐
│ 向量&知识存储层               │
│ - PostgreSQL 15 + pgvector    │
│ - Redis 7 (缓存)              │
│ - Chroma (开发)               │
└───────────────────────────────┘

观测性：OpenTelemetry + Prometheus + Grafana
```

---

## 第八部分：分阶段实施计划

**阶段1(第1-2周)：核心RAG引擎**
- 集成LangChain + LlamaIndex
- pgvector向量存储
- 文档导入和分块
- 交付物：RAG pipeline模块

**阶段2(第3周)：检索优化**
- Hybrid Search实现
- Cross-Encoder重排
- Query Expansion
- 交付物：性能对标报告

**阶段3(第4-5周)：Agent框架**
- ContentGeneratorAgent
- Prompt模板系统
- Agent协调机制
- 交付物：Agent框架代码

**阶段4(第6周)：前端UI和测试**
- 知识库管理UI
- 搜索测试工具
- 集成测试
- 交付物：前端组件 + 测试报告

---

## 第九部分：关键决策总结

| 决策点 | 方案 | 理由 |
|------|------|------|
| RAG框架 | LangChain + LlamaIndex | 互补优势，生态完整 |
| 向量DB | pgvector + Chroma | 成本低、与PG无缝集成 |
| Embedding | BAAI/bge-m3 | 中英混合、可微调、开源 |
| 分块 | 递归语义分块 | 保留语义、效果最优 |
| 检索 | Hybrid + Re-ranking | 精度最高 |
| 架构 | Harness Pipeline模式 | 可治理、可观测、易扩展 |

---

## 第十部分：常见陷阱和解决方案

### 陷阱1：为什么不用Dify/FastGPT全栈方案？
**答**：全栈平台导致技术债、定制困难、与FastAPI不兼容。采用框架方案长期ROI更高。

### 陷阱2：pgvector能处理多大规模？
**答**：500万向量可行；1000万需分片。GEO近期不会达到，pgvector足够。

### 陷阱3：Embedding模型需要微调吗？
**答**：第一版直接用pre-trained bge-m3。6个月后积累查询日志再微调（需500-10000三元组）。

### 陷阱4：Context Window溢出？
**答**：主动管理，不要等溢出。用tiktoken计数，确保检索结果在token预算内。

---

## 成本估算

| 项目 | 成本 |
|-----|------|
| 基础设施(已有) | 0 |
| 开源软件许可 | 0 |
| 核心开发(4周) | ~200K |
| RAG调优(2周) | ~100K |
| 测试(1周) | ~50K |
| **总计** | ~350K |

*相比SaaS服务年费30-50万，自建更经济*

---

## 后续研究方向

1. 多模态知识库（图表、表格、视频）
2. 知识图谱集成（实体关系抽取）
3. 主动学习（标注最有价值样本）
4. 联邦学习（企业隐私保护）
5. 自适应Chunking（按文档类型调整）