LLM项目中处理重复片段导致的数据库唯一约束冲突问题分析

在LLM项目开发过程中，开发者遇到了一个关于提示片段(fragments)管理的数据库约束问题。当用户尝试向同一个提示添加多个内容相同的片段时，系统会抛出"UNIQUE constraint failed"的完整性错误。

问题背景

LLM项目中的提示系统支持通过多个片段构建完整提示。每个提示响应(response)可以关联多个片段(fragments)，这些片段按照特定顺序组合形成最终发送给语言模型的完整提示内容。

在数据库设计中，最初为prompt_fragments表设置了(response_id, fragment_id)的组合唯一约束。这种设计在大多数情况下工作良好，但当用户尝试向同一个提示添加多个内容完全相同的片段时就会遇到问题。

问题重现

典型的错误场景出现在用户执行类似以下命令时：

llm -f https://example.com/robots.txt -f https://another.com/robots.txt "比较这两个robots.txt文件"

如果这两个URL指向的内容完全相同，系统会尝试创建两个具有相同response_id和fragment_id的记录，违反了现有的唯一约束条件。

技术分析

从数据库设计的角度来看，这个问题揭示了原有约束条件的不完备性。实际上，系统应该允许同一片段在同一个提示中多次出现，只要它们的顺序位置不同。

正确的唯一性约束应该考虑三个维度：

1. 所属的提示响应(response_id)
2. 片段内容标识(fragment_id)
3. 片段在提示中的顺序位置(order)

解决方案

项目维护者通过修改数据库模式解决了这个问题。新的解决方案：

1. 移除了原有的(response_id, fragment_id)唯一约束
2. 新增了(response_id, fragment_id, order)组合唯一约束
3. 确保数据库迁移脚本正确处理现有数据

这种修改既保持了数据的完整性，又支持了业务需求——允许相同内容片段在提示中多次出现，只要它们的位置不同。

实现意义

这个改进对用户体验有显著提升：

1. 用户现在可以自由地重复使用相同的片段内容构建提示
2. 系统行为更符合用户预期——无论片段内容是否重复，都能正确构建提示
3. 保持了数据一致性和完整性，防止了真正的重复记录产生

总结

这个案例展示了数据库设计中考虑业务实际需求的重要性。通过分析真实使用场景，开发者识别出了原有约束条件的不足，并通过扩展唯一性约束的维度提供了更符合用户期望的解决方案。这种改进既不影响系统稳定性，又增强了功能的灵活性。