人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载本指南围绕 TaskingAI 检索Retrieval模块中的 Record 删除操作展开基于代码模板 5_delete_a_record.md 讲解同步与异步两种删除调用方式并结合后端源码剖析删除时的级联清理、事务保障与计数回收机制。读完本文你将掌握通过taskingai.retrieval.delete_record/a_delete_record安全删除一条 Record 的完整流程以及删除后数据状态如何变化。前置背景Record 在 TaskingAI Retrieval 中的层级关系在 TaskingAI 的检索体系中数据按「Collection → Record → Chunk」三层组织Collection检索集合是知识库的顶层容器拥有capacity容量以 chunk 数为单位、num_records、num_chunks等统计字段参见 collection.pyRecord集合内的一条记录类型支持text、file、web三种见 record.py本身还携带title、content、metadata等属性ChunkRecord 内容经文本切分如TokenTextSplitter后得到的向量化片段是检索时的最小匹配单元。删除 Record 是数据生命周期管理中常见的清理操作当某条知识过期、被误写入或需要整体替换时可将其从集合中移除。需要注意的是TaskingAI 的删除是永久性删除——正如模板文档所述Record 会被彻底移除且与其关联的 chunks 也会一并删除执行后无法通过 API 找回。标准删除调用delete_record代码模板 5_delete_a_record.md 给出了最简洁的同步删除方式import taskingai taskingai.retrieval.delete_record( collection_id$$COLLECTION_ID$$, record_id$$RECORD_ID$$ )其中两个占位符参数需要替换为实际值参数类型必填说明collection_idstr是目标 Record 所属 Collection 的标识符可通过创建 Collection 的返回值获取record_idstr是待删除 Record 的标识符可通过创建 Record 或list_records获取异步变体a_delete_record同一目录下提供了异步版本模板 5_delete_a_record.mdasync适用于需要与async/await并发模型协同的场景import taskingai await taskingai.retrieval.a_delete_record( collection_id$$COLLECTION_ID$$, record_id$$RECORD_ID$$ )在asyncio驱动的应用中优先使用异步版本可避免阻塞事件循环两者的删除语义完全一致。获取 collection_id 与 record_id若你尚未持有这两个 ID可参考同目录模板先创建数据。创建 Record 时见 1_create_record.md返回值中带有record.record_idimport taskingai from taskingai.retrieval import Record, TokenTextSplitter record: Record taskingai.retrieval.create_record( collection_id$$COLLECTION_ID$$, typetext, contentMachine learning is a subfield of artificial intelligence..., text_splitterTokenTextSplitter(chunk_size200, chunk_overlap20), ) print(fcreated record: {record.record_id})删除背后的底层原理事务内的级联清理删除 Record 并非简单地从一张表中去掉一行而是涉及 chunk 清理与集合统计回退的级联操作。后端核心实现位于 backend/app/database_ops/retrieval/record/delete.pyasync def delete_record(record: Record): async with postgres_pool.get_db_connection() as conn: async with conn.transaction(): # 1. delete record chunks old_num_chunks await delete_record_chunks(conn, record.collection_id, record.record_id) # 2. delete from db await conn.execute( DELETE FROM record WHERE collection_id$1 AND record_id$2;, record.collection_id, record.record_id, ) # 3. update vectordb_collection num_records and num_chunks await conn.execute( UPDATE collection SET num_records num_records - 1, num_chunks num_chunks - $1 WHERE collection_id$2;, old_num_chunks, record.collection_id, )整个删除过程分为三个步骤全部包在同一个数据库事务中保证「chunk 删除、record 删除、集合计数更新」要么全部成功、要么全部回滚删除 Record 关联的所有 chunks通过delete_record_chunks从该 Collection 专属的 chunk 表中删除数据。每个 Collection 在 PostgreSQL 中对应一张独立的 chunk 表表名由Collection.get_chunk_table_name生成格式为c1_{collection_id}见 collection.py。在 utils.py 中该函数先COUNT出该 Record 的 chunk 数量再执行DELETE FROM {chunk_table_name} WHERE record_id $1并把数量返回给上层用于后续计数回退。删除 record 表中的记录行以collection_idrecord_id作为复合主键定位并删除Record 的主键即这两个字段的组合见 record.py。回退 Collection 的统计信息num_records减 1num_chunks减掉刚才实际删除的 chunk 数量old_num_chunks。从源码结构看第二步记录的是删除前该 Record 的实际 chunk 数而非预估数因此即使 Record 曾被部分删除过 chunk集合的num_chunks统计也能保持精确。上层调用链删除请求经由以下链路抵达数据库层见 operators/retrieval/record.pyRecordModelOperator.delete校验路径参数并加载collection与record实体调用db_record.delete_record(record)执行上文的三步事务通过collection_ops.redis.pop(collection)使 Collection 的缓存失效确保后续读取能拿到最新的统计值。HTTP API 视角DELETE 端点与响应Python SDK 的delete_record最终映射到后端 REST 接口。路由定义见 backend/app/routes/auto/record.pyDELETE /v1/collections/{collection_id}/records/{record_id}路径参数collection_id与record_id均为必填接口成功时返回RecordDeleteResponse内容固定为{status: success}见 record_delete_response.py不携带其他数据若目标 Record 不存在接口将返回错误响应测试中体现为OBJECT_NOT_FOUND。验证删除结果测试用例中的断言方式仓库自带的集成测试 test_record.py 完整演示了删除行为的验证方法res await delete_record(Retrieval.collection_id, record_id) res_json res.json() assert res.status_code 200 assert res_json.get(status) success get_res await get_record(Retrieval.collection_id, record_id) assert get_res.status_code 404 assert get_res_json.get(error).get(code) OBJECT_NOT_FOUND即删除成功返回200statussuccess随后再次查询该 Record 返回404错误码为OBJECT_NOT_FOUND。同一测试文件后续还断言了删除后 Collection 的num_records与num_chunks均归零验证了集合统计的正确回退test_record.py。HTTP 层的测试辅助函数可参考 backend/tests/api_services/retrieval/record.py它通过session.delete直接调用上述端点。实用注意事项不可逆操作delete_record是永久删除Record 及其 chunks 会从数据库中被物理移除DELETE语句不存在软删除或回收站机制执行前请务必确认record_id。容量自动释放删除后 Collection 的num_records与num_chunks同步回退意味着被占用的容量capacity随之释放可继续用于创建新的 Record。file 类型 Record 的更新限制从 record.py 的源码可以看出file类型 Record 不支持原地更新官方给出的替换方案正是「删除后重新创建」这也让删除成为文件类记录更新流程中的关键一环。批量清理场景如需清空整个 Collection可直接删除 Collection 本身其 chunk 表会被整体DROP见 collection/delete.py若仅清理部分数据则逐个delete_record更合适。相关阅读同目录下的完整 Record 操作模板创建 Record、查询单个 Record、更新 Record、列出 Records后端核心实现record 数据操作层、record 操作器、自动生成路由集成测试test_record.py 与 测试辅助函数赞分享人工智能大模型AI AgentRAG后端前端【免费下载链接】TaskingAIThe open source platform for AI-native application development.项目地址https://gitcode.com/gh_mirrors/ta/TaskingAI点击查看免费下载相关推荐TaskingAI 检索记录删除指南使用 Python SDK 从 Collection 中移除 Record 及其 ChunkTaskingAI 检索记录删除指南使用 Python SDK 从 Collection 中移除 Record 及其 Chunk 本指南聚焦 TaskingA人工智能大模型AI AgentRAG后端前端react-admin 软删除实践用 useHardDeleteMany 批量永久清除已删除记录react admin 软删除实践用 useHardDeleteMany 批量永久清除已删除记录 useHardDeleteMany 是 react admi前端UI组件react-admin 硬删除 Hook 完全指南useHardDelete 实现已删除记录的永久清除react admin 硬删除 Hook 完全指南useHardDelete 实现已删除记录的永久清除 useHardDelete 是 react admin前端UI组件上一篇如何用Label Studio快速构建多模态AI数据标注平台3分钟入门终极指南下一篇【亲测免费】 大可分离核注意力LSKA——重新定义CNN中的大核注意力设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考