LLM项目中的片段去重功能设计与实现

在大型语言模型应用中，处理重复的长文本提示是一个常见挑战。LLM项目通过引入片段(fragments)功能，优雅地解决了长文本提示的存储去重问题，同时优化了数据库存储效率。

问题背景

当开发者频繁使用包含长文档作为上下文的大语言模型时，数据库会存储大量重复的长文本内容。例如，将项目文档作为上下文反复使用时，每次交互都会在数据库中创建完整副本，导致存储空间浪费。

设计方案演进

项目维护者最初考虑了多种解决方案：

1. 复用附件机制：利用现有的附件表存储文本内容，但存在类型混淆问题
2. 全量外键分离：将所有提示文本移至单独表，但增加了短文本的查询复杂度
3. 自动阈值分离：基于长度阈值自动分离长文本，但缺乏用户控制
4. 显式片段指定：最终采纳的方案，允许用户显式指定需要去重的文本片段

最终实现方案

核心设计包含以下组件：

1. 上下文表(contexts)：存储去重后的文本内容，使用SHA256哈希作为主键
2. 响应表改造：在responses表中添加prompt_id和system_id外键
3. 命令行接口：新增-f/--file和-u/--url参数显式指定片段来源

关键技术实现包括：

# 存储时检查并处理长文本
if len(prompt) > THRESHOLD:
    context = get_or_create_context(prompt)
    response.prompt_id = context.id
else:
    response.prompt = prompt

技术挑战与解决方案

1. 搜索功能适配：

   • 原全文搜索基于responses表的prompt列
   • 新增contexts_fts表单独索引片段内容
   • 接受跨表搜索相关性评分的小幅下降

2. 模板系统兼容：

   • 保持现有模板功能不变
   • 未来可扩展支持片段中的变量替换

3. 数据库迁移策略：

   • 使用SQLite的transform功能重构表结构
   • 确保现有数据兼容性
   • 处理全文搜索索引重建

使用示例

开发者现在可以高效地使用长文档作为上下文：

# 使用本地文件作为片段
llm -f documentation.md "解释核心功能"

# 组合多个片段
llm -f intro.md -f api.md "如何调用主要接口？"

# 使用URL内容
llm -u https://example.com/docs.txt "总结使用说明"

性能优化效果

在实际使用中，该设计显著减少了数据库存储需求：

1. 332KB的文档重复使用2次，从664KB降至332KB+少量元数据
2. 对于高频使用的系统提示，存储节省随使用次数线性增长
3. 减少了数据库备份和传输的开销

设计哲学

该功能体现了几个重要的设计原则：

1. 显式优于隐式：通过明确命令行参数控制去重行为
2. 渐进式改进：不影响现有功能的前提下添加新能力
3. 实用主义：在完美解决方案和实际可用性间取得平衡

未来扩展方向

1. 片段变量支持：在去重片段中支持模板变量
2. 片段管理命令：查看、清理未使用的片段
3. 跨会话片段共享：团队协作时共享常用上下文

这一功能的引入不仅解决了存储效率问题，还为LLM项目未来的上下文管理功能奠定了坚实基础。