Product Sync — 2026-05-20

Product Sync — 2026-05-20【免费下载链接】cocoindexIncremental engine for long horizon agents Star if you like it!项目地址: https://gitcode.com/GitHub_Trending/co/cocoindexOrganizer: Alice Chen Participants: Bob Lee, Alice C.Notes: The team reviewed the release checklist and prioritized docs polish.Tasks:Bob Lee: Update the migration guide.Alice Chen: Confirm launch metrics.Infra Review — 2026-05-21Organizer: Robert Lee Participants: Alice Chen, Carol SinghNotes: The group reviewed graph database hosting options and fallback plans.Tasks:Carol Singh: Prepare the FalkorDB deployment notes.Bob Lee: Validate backup restore.从源码 [main.rs](https://link.gitcode.com/i/e022096f66735eccc72bf5a29091eb90) 的 extract_meeting 可以反推每一段的字段规范 - **标题行**以 #/## 开头末尾以 — em dash或 - 分隔出 YYYY-MM-DD 日期日期用 NaiveDate::parse_from_str(date.trim(), %Y-%m-%d) 解析解析失败会抛出 invalid meeting date 引擎错误。 - **Organizer: 前缀行**记录组织者姓名缺省会直接报 meeting section lacks organizer 错误。 - **Participants: 前缀行**逗号分隔的参与者列表解析时会 split(,) 后逐项 trim 并过滤空串。 - **Notes: 前缀行**整段纪要的摘要文本。 - **Tasks: 段**其后的 - 列表项被视为任务每行按**第一个冒号**切出负责人与任务描述task.split_once(:)冒号缺失会报 task lacks assignee 错误。 这个格式刻意与 Python 版 LLM 抽取产物的语义对齐组织者/参与者/任务/负责人只是把LLM 从自然语言抽取换成了确定性结构化解析从而在本地无需模型即可复现同一张图谱。 ## 三、切分与解析从纯文本到结构化记录 ### 3.1 按标题切分会议段落 [split_meetings](https://link.gitcode.com/i/010a00d8ef2faa778484d0ece97bf093) 遍历文本的每一行遇到以 # 或 ## 开头的行即开启新段落把切出的各段去除首尾空白后返回。对 notes.md 而言最终得到Product Sync — 2026-05-20与Infra Review — 2026-05-21两个独立段落后续每个段落独立建一个 Meeting 节点。 ### 3.2 逐段抽取字段 [extract_meeting](https://link.gitcode.com/i/e022096f66735eccc72bf5a29091eb90) 在段落内部用前缀匹配逐行扫描产出 ExtractedMeeting { time, note, organizer, participants, tasks } 结构。需要留意几个工程细节 - 用 in_tasks 状态位标记是否进入 Tasks: 区域避免把 Tasks: 之后的普通文本误当任务 - 任务负责人最初被建模为 VecStringassigned_to为后续规范化与去重留下空间 - 所有字段缺失都有显式报错保证坏数据快失败而不是写进半成品图。 ### 3.3 人员名称规范化 示例用 [canonical_person](https://link.gitcode.com/i/84ece03e83512a343216328b9ee75125) 做**确定性实体消歧**它等价于 Python 版中嵌入 LLM 实体解析这一阶段的本地替身 rust fn canonical_person(name: str) - String { match name.trim() { Alice C. Alice Chen.to_string(), Bob Lee Robert Lee.to_string(), other other.to_string(), } }对notes.md的实际效果第一次会议中Participants: Bob Lee, Alice C.被归一为Robert Lee与Alice Chen第二次会议中Organizer: Robert Lee与任务负责人Bob Lee也统一落到Robert Lee。于是最终Person节点只有三个Alice Chen、Robert Lee、Carol Singh同一人在不同会议、不同角色组织者/参与者/负责人下都会被折叠成同一个节点——这正是知识图谱人作为共享实体的核心诉求。四、图谱构建节点、关系与稳定主键4.1 挂载三类节点表build_graph 首先用falkordb::mount_table_target声明节点表。以Meeting表为例let meeting_table falkordb::mount_table_target( ctx, graph, Meeting, schema([ (id, integer), (note_file, string), (time, string), (note, string), ], id)?, ).await?;schema辅助函数main.rs L56-L63把列名 Cypher 类型组装成falkordb::TableSchema。对应到 SDK 侧TableSchema::new 会校验列名与主键是否合法validate_ident并要求主键必须存在于列集合中从根上规避注入与拼写错误。Person与Task表同理主键分别是name与description。4.2 挂载三条关系关系目标通过 mount_relation_target 挂在两个端点表之上let attended_rel falkordb::mount_relation_target(ctx, graph, ATTENDED, person_table, meeting_table).await?; let decided_rel falkordb::mount_relation_target(ctx, graph, DECIDED, meeting_table, task_table).await?; let assigned_rel falkordb::mount_relation_target(ctx, graph, ASSIGNED_TO, person_table, task_table).await?;在 SDK 实现中relation_target_state 会把关系建模为一张没有 schema 的表TableSpec::relation只保留from_table/to_table端点信息主键固定为id。这正是 Python 版注释中所说的端点派生主键机制——每条关系的主键由(from_table, from_id, to_table, to_id)组合自动生成见 RelationTarget::declare_relation_record 中的relation_key保证同一对端点之间至多一条边天然去重。4.3 稳定主键与数据声明会议 id 由 IdGenerator::next_id 基于(note_file, time)确定性生成因此同一个文件里同一日期的会议在多次运行中保持同一 id这是增量对账能工作的前提。节点与关系的声明接口统一为declare_record/declare_relationmeeting_table.declare_record(ctx, meeting_id, Meeting { id: meeting_id, note_file, time, note })?; task_table.declare_record(ctx, task.description.as_str(), Task { description })?; decided_rel.declare_relation(ctx, meeting_id, task.description.as_str())?;人员相关的ATTENDED还携带属性载荷AttendedRel { is_organizer }通过 declare_relation_record 写入。这里有一个值得一提的聚合细节同一会议中某人在组织者与参与者列表里同时出现时如第二次会议的Robert Lee既当组织者又是Bob Lee的归一目标示例用BTreeMapString, bool聚合组织者标志true优先main.rs L253-L260最终只落一条ATTENDED边。4.4 目录扫描输入文件通过fs::walk(input_dir, [**/*.md])收集main.rs L191每个.md文件独立读取文本因而支持把纪要按文件/日期拆分存放示例默认扫描input/目录。五、运行方式与图谱查询5.1 启动 FalkorDB镜像自带 3000 端口的浏览器 UIdocker run -d --name cocoindex-falkordb-rust \ -p 6379:6379 -p 3000:3000 \ falkordb/falkordb:latest5.2 构建图谱export FALKORDB_URIfalkor://localhost:6379 export FALKORDB_GRAPHmeeting_notes cargo run两个环境变量都有默认值兜底见 main.rs L288-L291FALKORDB_URI默认falkor://localhost:6379FALKORDB_GRAPH默认meeting_notes同时支持把输入目录作为第一个命令行参数传入默认{CARGO_MANIFEST_DIR}/input。应用状态库.cocoindex_db落在项目目录下main.rs L293-L296用于记录上次声明了什么是增量对账的本地底座。依赖声明见 Cargo.toml核心是开启falkordbfeature 的cocoindex本地 SDK配合tokio、serde、chrono解析会议日期与dotenvy读取.env。5.3 用 redis-cli 查询图谱FalkorDB 本质是 Redis 模块Cypher 查询直接走GRAPH.QUERY# 导出全部边节点与关系的连接形态 redis-cli GRAPH.QUERY meeting_notes MATCH p()--() RETURN p # 谁参加了哪次会议 redis-cli GRAPH.QUERY meeting_notes \ MATCH (p:Person)-[:ATTENDED]-(m:Meeting) RETURN p.name, m.time, m.note_file【免费下载链接】cocoindexIncremental engine for long horizon agents Star if you like it!项目地址: https://gitcode.com/GitHub_Trending/co/cocoindex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考