RAG 的演化：MCP 服务器的基因组和缓存

基于遗传算法的RAG管道演进：在MCP服务器上的实现

随着查询变化，使用静态提示的RAG系统会逐渐失效。实施受控演进利用LLM生成“基因组”——管道配置的变体。评估器在查询样本上测试它们，最佳候选者进入待批准状态，由管理员手动确认。应用于MCP服务器文档1c（针对1C文档的RAG），包含三个层次：后处理、路由、缓存策略。

演进并非自主进行，而是在管理面板的实验室循环中操作。重点在于改进1C文档领域的系统提示和缓存策略，并可能扩展到金融、会计和法律领域。

三层管道的架构

文档搜索管道按顺序处理查询：

• 语义块搜索（必要时采用混合方式）。
• 路由：分类器确定查询类型（事实查找、解释、BSL帮助）并激活一个配置文件，包含系统提示、深度预算、格式。
• 后处理：LLM根据活动基因组中的合同（答案、关键点、来源、警告）组装响应。
• 缓存策略：写入缓存前的准入控制（最小来源数、如有警告则阻止）。

| 层次 | 演进对象 | 影响 |

|------|-----------------|---------|

| 后处理 | 系统提示、块数、最大令牌数 | 文本响应的质量 |

| 路由 | 分类器提示、配置文件 | 适应查询类型 |

| 缓存策略 | 准入阈值（最小支持度） | 缓存过滤 |

后处理和路由实时修改响应，而缓存策略仅影响存储。

基因组和评估的数据模型

基因组存储在evolution_genome表中，作为JSONB字段：层次、状态（候选 → 已评估 → 待批准 → 活动）、基因组、分数。

class EvolutionGenome(Base):
    layer = Column(String(32), nullable=False, index=True)
    status = Column(String(32), nullable=False, default="candidate", index=True)
    genome = Column(JSONB, nullable=False)
    score = Column(Float, nullable=True)
    eval_results = relationship("EvolutionEvalResult", back_populates="genome")

每个评估结果记录查询、响应（最多2000字符）、评估分数（0–10）、来自LLM评估器的评估推理。

class EvolutionEvalResult(Base):
    genome_id = Column(Integer, ForeignKey("evolution_genome.id"), nullable=False)
    query = Column(Text, nullable=False)
    response = Column(Text, nullable=True)
    judge_score = Column(Float, nullable=True)
    judge_reasoning = Column(Text, nullable=True)

对于路由，生成eval_seed_prompt——一个代理+MCP的测试会话。

演进周期：从突变到生产

周期：生成突变() → 评估基因组() → 提升最佳() → 手动批准。

• 生成：基础基因组（活动或默认基因组）+ 来自MCP文档1c缓存的N个查询-响应对。LLM生成N个JSON变体{"genome": {...}, "notes": "..."}。
• 评估：评估器（rag_postprocess_model）根据标准检查：完整性、准确性、来源、简洁性。样本平均分数。
• 提升：最佳候选者移至待批准。
• 激活：管理员在UI中确认。

按层次生成突变

后处理：系统提示中的突变（组装响应的指令，考虑客户端/服务器上下文）、system_prompt_reduce（合并无重复）、块数（15–20）、最大令牌数（4096–8192）、引用策略（始终/内联）、详细程度（自适应/全面）。

示例后处理基因组：

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "您是1C专家。回答时，始终考虑执行上下文（瘦客户端、Web客户端、服务器、移动应用）。用俄语回答。引用来源。",
  "citation_policy": "always",
  "system_prompt_reduce": "合并响应，清晰区分不同执行上下文的建议。去除重复。"
}

路由：分类器提示 + 按查询类型的配置文件（系统提示、深度预算、格式）。

缓存策略：最小支持度、要求来源、最小来源数、如有警告则阻止、关键点最小置信度。

真实对话被添加到生成器上下文中以分析弱点。

评估和评估器指标

评估器基于4个指标（0–10）进行评估：

• 完整性：查询的覆盖范围。
• 准确性：与块的对齐。
• 来源：引用的存在/质量。
• 简洁性：无冗余内容。

平均分数决定提升。Eval_judge_response存储原始LLM输出。

关键点

• 层次演进独立：后处理改进文本，缓存策略提升缓存质量。
• 手动批准防止生产中的回归。
• 来自真实缓存的上下文增加突变相关性。
• SQLAlchemy模型支持评估结果的级联删除。
• 可扩展到多领域（1C + 金融 + 编码）。

扩展和最佳实践

扩展：为领域添加层次（金融：考虑参考数据的系统提示；编码：BSL语法）。在缓存的10–20个查询上测试。监控分数 >8.5以批准。避免过拟合——限制每个周期的突变数。

— Editorial Team