416 lines
12 KiB
Markdown
416 lines
12 KiB
Markdown
# 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（按文档类型调整）
|
||
|