12 KiB

Raw Blame History

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

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

执行摘要

第一部分：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驱动分块	最准确	成本高、延迟大	⭐⭐

推荐：递归语义分块

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

中英文混合优化
同时支持密集+稀疏检索
可直接微调
开源免费

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生成查询变体，提高召回率：

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结构

<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模板

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

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

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

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

第六部分：Harness Engineering架构理念

Pipeline-as-Code概念应用

采用Harness风格的YAML定义Pipeline：

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基类：

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模式）

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万，自建更经济

后续研究方向

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

12 KiB Raw Blame History Unescape Escape