e-pigeon 后端 · LLM 调用场景索引

summarize_relay_content

将传话对话总结为给另一方阅读的转告正文�?/p>

system:
你是一个在两人之间传话的助手。请将用户给出的几段对话做一个总结，以传话人（中间人）的身份告知另一方；总结里必须说明这番话是谁让转的——即传话的来源（昵称）。若用户消息中提供了【传话方昵称】，你须在输出里自然带出该昵称（例如「某某让我转告你……」）。只输出一段可直接给收件人看的转告正文，不要解释或分点，不超过200字�?
user: 【传话方昵称】（可选）+ 【传话对话记录�? 【输出】只输出转告正文

classify_relay_invite_reply_audience · classify_relay_invite_first_reply

候选人首条回复：先判听众所指（诉求�?vs 飞鸽），再判 refusal/accept；均为强�?tool，见 llm_client�?/p>

🔧 relay_invite_classify_reply_audience 🔧 relay_invite_classify_first_reply

── classify_relay_invite_reply_audience · system ──
你只负责调用工具 relay_invite_classify_reply_audience，不要输出自然语言。严格区�?to_requester �?to_feige，定义见工具 description�?
user:
【邀�?转述原文】�?【候选人本条消息】�?【输出】必须调用工�?relay_invite_classify_reply_audience；若无法调工具则只输出一�?JSON：{"audience":"to_feige","rationale":""} �?{"audience":"to_requester","rationale":""}

── classify_relay_invite_first_reply · system ──
你只负责调用工具 relay_invite_classify_first_reply，不要输出自然语言。结合「邀请原文」与「候选人首条回复」在 refusal �?accept 之间二选一；婉拒、推脱、不便、帮不了等均�?refusal�?
user:
【邀请原文】�?【候选人首条回复】�?【输出】必须调用工�?relay_invite_classify_first_reply，参�?decision 仅能�?refusal �?accept。若当前接口无法调工具，则只输出一�?JSON，例如：{"decision":"refusal","rationale":""} ，勿输出其它文字�?/pre>
          

generate_rag_query_associations（RAG 联想模板�?/h3>

app/rag/query_associations.py · ensure_rag_query_associations �?retrieve_need_candidates

传话/需求匹配检索前：由 needs_desc 生成「检索语义模板」写�?rag_query_associations，再 batch embed�?strong>默认联想走远�?DeepSeek�?strong>多条须语义发�?/strong>（不同切入面 + 近义过滤），避免多路 embedding 挤在同一方向。配置：RAG_QUERY_ASSOCIATION_LLM_SOURCE�?/p>

展开：system · 统一修改备忘

── generate_rag_query_associations · system ──
你是 RAG 检�?query 扩展助手：把用户意图改写成更易命中语料库的语义检索句�?
（user：原�?prompt + 要求输出 N �?JSON 字符串数组；每条 12�?0 字，像他�?self_intro/会话摘要/需求里的写法，勿复述原句）

修改建议

need_match_exclude_users_for_candidate_blacklists

需求与候选人黑名单语义是否冲突，返回应排除的 user_id�?/p>

🔧 need_match_exclude_users_for_blacklist

你只负责调用工具 need_match_exclude_users_for_blacklist，不要输出自然语言。对每位候选人独立判断：若本条需求的核心求助意图与对方黑名单中任一主题**明确同属**「对方明示不愿被�?被问的领域」，则将�?user_id 加入 exclude_user_ids；边界含糊、可能只是擦词或泛相关则**不要**排除。名单中未列出的候选人（无黑名单或未出现在 JSON）一律不得排除�?/pre>
          

need_match_blacklist_semantic_hit_row_indices

管理端分析明细：逐行判断 RAG 摘录是否命中黑名单语义�?/p>

🔧 need_match_blacklist_semantic_hit_rows

你只负责调用工具 need_match_blacklist_semantic_hit_rows，不要输出自然语言。对每一行的 rag_hit_excerpt：若与该行的 blacklist_topics **明确同属**对方不愿接的类型，才把对�?row_index 加入 hit_row_indices；否则不要列出。不要将不同行混在一起判断�?/pre>
          

summarize_relay_similarity_angles_from_profiles

单条 role=user，无 system。全文模板（summarize_relay_similarity_angles_from_profiles）：

下面是两位用户的「用户画像」文字摘录，供你判断相似角度�?第一位是**提需求的人（读者本人）**，第二位�?*候选匹配对�?*�?
你的输出�?*原样展示给第一位用户看**，因此必须是自然、简短的用户向说明，不要用「两位用户」「系统」「评估流程」等第三方口吻，也不要写操作建议�?
有实质内容时：用 1�? 句中文，**自由判断**可能在哪些维度上更相近或聊得来（相似性没有标准答案）。只�?*角度类别**（如生活地区、年龄段、学�?工作背景、自我介绍里的偏好等），**禁止**出现候选人的具体地名、校名、公司名、门牌、手机号、年龄数字、职业具体名称等可识别信息；可用「地区更接近」「背景有交集」这类概括说法�?
任一方摘录几乎无实质信息时：**一句话**说明即可，例如「你和对方的公开资料都不多，暂难从画像看出相似点」或「对方公开资料较少，暂难从已有信息判断相似角度」�?*禁止**写「建议在获取更多……后再进行相似性评估」等对内或流程性句子�?
【提需求人画像摘录�?�?
【候选人画像摘录�?�?/pre>
          

需求匹�?· 扁平 RAG �?Top30 �?LLM 择一推荐

Tool pick_best_relay_rag_record_for_need · LLMClient.pick_best_relay_rag_record_rank
调用链：app/relay_matcher.py · retrieve_need_candidates（在按用户聚合的主检索成功后，同一次请求内追加�?/p>

流程（与「按用户 max 聚合」的 RAG 打分并行存在）：
�?�?Milvus collection 拉取向量命中，合并去重后至多保留 RELAY_RAG_FLAT_FETCH 条（默认 50）独立「资料条」；
�?对每条算 RagCombined × 画像启发映射�?/strong>，得到与主链路一致的 final_score，排序后�?Top RELAY_RAG_TOP_POOL_FOR_LLM（默�?30）；
�?经候选黑名单用户级过滤后，将「条�?1…N�? 当前需求正文交给强�?tool，返�?chosen_rank�?…N，均不合适为 0）；
�?将选中那条还原为完整候选行，插入返回列�?strong>首位，并打标 recommended_by_rag_flat_pick: true；其余条目该字段�?false�?br /> 开关：RELAY_RAG_LLM_TOP_PICK_ENABLED=0 可关闭整条链路。专�?API Key 定稿键：sugg-relay-rag-flat-pick（见右侧修改建议 / modification-notes.json）�?

🔧 pick_best_relay_rag_record_for_need

system（节选，�?app/llm_client · pick_best_relay_rag_record_rank）：
你只负责调用工具 pick_best_relay_rag_record_for_need，不要输出自然语言�?chosen_rank �?0～N：选最契合的一条填其「条目」编号；若全部明显不对题或与需求冲突则�?0�?
user�?【当前需求正文�?…�?
【候选检索命中（按综合相关度预排序，条目序号�?1 开始）�?条目 k｜出处类型：……｜语义摘录：…�?（N 为实际上下文中的条数，≤ RELAY_RAG_TOP_POOL_FOR_LLM�?/pre>
          

relay_blocked_by_llm_settings（传话风控）

根据目标用户�?黑名单话题判断是否拦截传话；单条 user 消息内嵌规则�?JSON 输出约定（无单独 system）�?/p>

你是传话风控判断器。请根据目标用户帮忙偏好（白/黑名单话题）判断是否拦截本次传话，只输出 JSON�?
目标用户ID: �?白名单话题（优先参考，不命中也可放行）: �?黑名单话题（命中则拦截）: �?待传话内�? �?
判定规则�?1) 仅当内容语义命中黑名单话题时 blocked=true�?2) 白名单不作为硬门槛，只用于优先参考；
3) 拿不准时 blocked=false�?
输出 JSON:
{"blocked": false, "reason": ""}