Yêu cầu của task này là cho trước một topic, mô tả bằng text và các image/video example, tìm trong test set top 1,000 relevant shots với topic đó. Xem dưới đây một ví dụ về search topic:
Find shots of 3 or fewer people sitting at a table
Đối với search task, các hệ thống có thể phân thành 3 loại. Loại thứ nhất là automatic, nghĩa là hệ thống sẽ nhận vào topic như mô tả ở trên (bao gồm text, image và video), để từ đó trả ra top 1,000 shots như yêu cầu. Loại thứ hai gọi là manual, nghĩa là người dùng sẽ chuyển ngữ (translate) topic về gần cách hiểu của máy tính hơn (ví dụ, chỉ lấy ra các từ khóa như people, table, sitting), sau đó là hệ thống phải xử lí và trả về các kết quả. Loại thứ ba là interactive, nghĩa là hệ thống và người dùng sẽ tương tác với nhau để tìm ra kết quả (giống như Google). Ở loại thứ ba, thời gian (bao gồm thời gian hệ thống xử lí và thời gian tương tác với người dùng) giới hạn để tìm ra 1,000 shots là 10 phút (mấy năm trước là 15 phút).
Trước kia, khi nghe hệ thống video search thực hiện automatic search như mô tả ở trên, tôi hầu như không tin vào tính khả thi của nó. Theo dõi kết quả của những năm gần đây, thì thấy MAP (mean average precision) tốt nhất cho loại automatic này là khoảng 9% (nôm na có thể hiểu, trong top 10 shots trả về, có không quá 2 relevant shots), trong khi MAP tốt nhất cho loại interactive là 30%. So với concept detection task, kết quả tốt nhất MAP dao động từ 13-20%, thì kết quả này đúng là không tệ. Những kết quả, ví dụ như MAP 10%, nếu nói trong cộng đồng TRECVID thì có thể tự hào; nhưng nếu nói cho người dùng bình thường, con số này không có chút ấn tượng nào. Vì kết quả của nghiên cứu vẫn còn khoảng cách khá xa so với mong đợi của người dùng nên có thể thấy, phải khoảng 5-10 năm nữa, mới có thể có sản phẩm về video search thực sự.
Để chuẩn bị cho task này, tôi đã thử tìm hiểu về các cách tiếp cận trước đó xem người ta làm thế nào. Thì ra, các hệ thống state of the art hiện nay hầu như đều có cấu trúc khá giống nhau. Xem hình cấu trúc của hệ thống mà IBM research ở tập tin đính kèm. Có 2 thành phần chính: thành phần thứ nhất là xử lí text của câu query, thành phần thứ hai là xử lí ngữ nghĩa của image/video minh họa cho câu query. Trong thành phần thứ hai này, người ta thường tách làm hai thành phần con, thành phần thứ nhất xử lí low-level features của image/video, ví dụ color, texture, shape; thành phần thứ hai xử lí high-level features, ví dụ crowd, animal, people. Các high-level features chính là các concepts trong concept detection task. Có thể thấy, hai tasks concept detection và search có mối liên hệ chặt chẽ với nhau như thế nào.
Để xử lí text trong câu query, các nhóm đã thực hiện khá nhiều NLP techniques, ví dụ dùng các kĩ thuật liên quan đến query expansion (ví dụ, một từ có thể có nhiều biến thể khác nhau, sitting --> sit, sits, sat, etc, people --> human beings), keyword extraction, dùng n-gram. Tôi chỉ biết chút ít về mấy thứ này, nhưng thấy cách mà các nhóm làm, ví dụ tham chiếu WordNet, xây dựng các mô hình ngữ nghĩa, thì thấy mình không có cửa. Cũng xin nói thêm là TRECVID được tiến hóa từ một task con của TREC - text retrieval benchmark, do đó các nhóm tham gia phần lớn xuất thân từ text retrieval nên họ rất rành về mấy thứ này. Có một thực tế là nếu chỉ dùng text để match giữa query và transcript (có được từ ASR/MT - nhận dạng tiếng nói và dịch máy tự động), thì kết quả không cao, chỉ khoảng 1-2% mà thôi, nhưng nếu kết hợp text và visual information thì kết quả sẽ là tốt nhất. Do đó dù muốn hay không vẫn phải xử lí text ở mức đơn giản nhất.
Vì TRECVID yêu cầu phải có ít nhất 1 baseline run chỉ dùng text (nghĩa là hệ thống nhận vào câu query: Find shots of 3 or fewer people sitting a table, rồi trả ra kết quả), cho nên tôi cũng phải thực hiện một run như vậy. Dự định của tôi là tôi sẽ dùng Lucene. Các kĩ thuật liên quan đến text retrieval cho full text search đều đã được cài đặt trong Lucene (xem thêm ở đây), nên phần còn lại chỉ là cung cấp cho Lucene biết đâu là document cần để index mà thôi. Trong trường hợp của video search, mỗi document chính là text liên quan đến mỗi shot. Do thời gian mỗi shot khá ngắn (có thể khoảng 2 giây mà thôi), cho nên kĩ thuật thông thường là nới rộng shot hiện hành về 2 bên và lấy thêm text từ các shots này. Text của mỗi shot chính là transcript được cung cấp từ ASR/MT. Do test video là tiếng Hà Lan (Dutch), nên nếu thích thì có thể translate câu query sang tiếng Hà Lan, và search trên đó thay vì dùng kết quả MT để search trên tiếng Anh.
Để xử lí visual information dùng high-level features, cách đơn giản nhất là xem câu query đó tương ứng với concept nào, ví dụ câu query: Find shots of 3 or fewer people sitting a table, concept gần nhất là people. Sau khi có concept rồi thì dùng kết quả của concept detection để trả kết quả về. Cách làm này đã bỏ mất khá nhiều thông tin, ví dụ câu query yêu cầu ít hơn 3 người, và yêu cầu họ phải ngồi cạnh một cái bàn. Do đó, kết quả vẫn rất khó cao. Nếu dùng low-level feature, ví dụ như color hay texture, thì cũng có hạn chế của nó. Ví dụ cái bàn trong ảnh minh họa là bàn tròn, nhưng trong dữ liệu test có thể có bàn vuông, bàn hình chữ U chẳng hạn, vậy là khó mà tìm ra.
Vì mỗi thành phần đều có hạn chế của nó, do đó, người ta chỉ xem nó là kết quả trung gian. Thông thường, phải có thêm một bước kết hợp các kết quả trung gian này lại, đó là bước fusion. Thực tế đã cho thấy rằng, chỉ có fusion, kết quả mới hi vọng cao được.
Tôi cũng sẽ đi theo các hướng thông dụng này. Cụ thể là tôi sẽ train một tập gồm 374 các concept detectors để đánh giá xem mỗi shot trong test set thuộc về các concept nào, rồi từ đó chọn ra một hoặc vài conceps phù hợp nhất cho câu query và trả kết quả về. Cũng nói thêm ở đây là việc train các concept detectors là tốn tài nguyên và thời gian nên các nhóm thường sử dụng kết quả của các nhóm thực hiện concept detection task. Tuy nhiên số lượng các concept của task này bị giới hạn ở con số 20 hoặc 40 mà thôi. Mô tả một câu query mà chỉ chọn trong số 40 concepts thì quá bị giới hạn. Cho đến nay, chỉ có một số nhóm có thể train được hàng trăm concepts, đó là Columbia Univ, IBM, MediaMill và CityU-HK. Lí do có ít số nhóm là vì đây là các nhóm cho kết quả ở concept detection task khá tốt nên kết quả của họ là có thể tin cậy để dùng. NII đã có kết quả khá tốt ở TRECVID 2007 nên hi vọng kết quả của việc mở rộng ra 374 concepts là có thể tin cậy. (Con số 374 là vì đây là số lượng concept có annotation để training). Việc training 374 concept này có thể phải mất cả 1-2 tuần và tài nguyên khá lớn, do đó tôi sẽ phải tiến hành ngay vào tuần tới.
Các techniques khác như dùng low-level feature, fusion, tôi cũng đã có tool sẵn, do đó hi vọng có thể hiệu chỉnh để có được kết quả trong thời gian ngắn. Deadline của search task là 12 Sep. Trước mắt là lo cho Star Challenge, sau đó từ 04 Sep là lo cho vụ này, nghĩa là có khoảng 1 tuần. Life is hard.
Lê Đình Duy
Xem đầy đủ bài viết tại http://ledduy.blogspot.com/2009/07/trecvid-2008-semantic-video-search-task.html
No comments:
Post a Comment